Apicloud-based hybrid application development framework

APICloud integration including window systems, application management, network communication, data storage, news events, device access, UI components, multimedia, and other functions, these functions requires no additional plugin support can be called directly, can be said to be worthy of “out of the box,” the official document with the introduction of the API or very detailed, It’s hard to know where to start when you first open a document, but here’s an example of what APICloud offers, and why it still needs to be repackaged in real projects.

Multiple WebViews are at the heart of APICloud, which means that an APP, like a website, is made up of several separate pages that open in sequence, forming a stack with the most recently opened pages on top and the previously opened ones at the bottom. The ability to navigate through the page stack by going back, jumping, closing, etc., is provided by the windowing system, which includes at least the following functions:

• Open/close the page
• Open/close the floating window
• The jump page
• Jump floating window
• Execute scripts across pages
• The local store
• Page status monitoring
• Global event publish/subscribe

These functions are sufficient to meet all the needs of window management, and some of them are even very powerful. For example, cross-page scripting means that you can execute A specific script from page A remotely from page B. There is also the ability to manipulate the stack directly, such as placing a specified page/floating window top/bottom; There is also a very useful publish and subscribe mechanism, which is an effective tool to break through page barriers.

It’s functional enough, but you probably won’t be able to write code after reading it.

It’s not unusual for a slightly more complex APP to have dozens or hundreds of pages, so the first thing that APP code organization needs to address is page organization.

For sure, the pages should be managed together, but they can’t be listed directly. Then create a view/ folder first, and then divide it into two folders according to function modules. Put the member-related pages into member/ and the product pages into product/… ; Page scripts and styles do not want to be inline, it is best to have three files for each page, template, style and script, then put them in a folder, named after the page name. The pagefile is channel-page-pagefile, and the directory looks like this:

view/

| - member / / / member columns

| | - info / / / member information page

 |      |        |--- temp.html

 |      |        |--- style.css

 |      |        `--- script.js

| ` - set / / / member Settings page

 |              |--- temp.html

 |              |--- style.css

 |              `--- script.js

 |      

| - home / / / APP homepage

 |      |--- temp.html

 |      |--- style.css

 |      `--- script.js

.

Copy the code

So even if there are more pages, find there are telltale signs, not see spent eyes in this file, the page style and split the script is also easy to develop, because once page code is very long, up and down the bala CSS and js also pretty painful, cleanly than apart, it’s a local file, little loading problem, Another advantage of organizing your pages as folders is that you can keep all of your unique resources in your own folders, so you don’t have to put all of your images in a public folder. When you look at a bunch of images in the future, you won’t know which ones are useful and which ones aren’t.

Then there is script organization. APP development needs to write a large number of JS. The purpose of ORGANIZING JS is to filter layers of non-business code out, so that more attention can be paid to the development of business scripts.

The first step is definitely to separate the class library from the business into plug-ins, services, and common scripts.

Common scripts are things like back button listening, image click listening, compatibility handling, etc. Every page should reference it (except root). You can pull all of them into common.js for easy modification. There are also some common business methods, such as formatting, looking up coordinates, etc., not every page can be used, but it is also necessary to centralized management, for the moment called him server.js; Other plugin scripts, such as upload and form validation, are packaged into modules and placed in modules/ folders. Finally, there is the class library, which is also the core of the framework. We call it core.js, which contains common class libraries and secondary encapsulation of the engine interface. The secondary encapsulation has at least three advantages. It’s like death to me; Second, if the API of the underlying engine is updated, there is no need to modify the business code, just change the corresponding package in core.js. Third, it is convenient to replace the bottom layer. In fact, the prototype of this framework is based on Appcan. Later, it is nothing more than changing a set of bottom API when switching to APICloud.

All that is left is script.js scattered across the pages, so the final script organization looks like this:

|--- sdk/

|       |--- modules/

|       |      |--- upload.js

| | | -- -...

|       |--- core.js

|       |--- server.js

|       `--- common.js

|--- view/

|       |--- page/

|       |       |--- script.js

| | -...

Copy the code

The organization of CSS and other static resources is very simple, and there is no need to go into detail. Here is a complete directory structure:

| - docs / / / the document (no need to upload packing platform)

| - error / / / app error pages

| - res / / / app static resources (images, templates, etc.)

|-- sdk/ 

| | - modules / / / plug-in modules

| | - the font / / / fonts icon

. | | - core js / / core library

| | - server. Js / / business methods

. | | - common js / / common code page

| ` -- UI. CSS / / common style

| - view / / / app page

| -- config. Js / / framework configuration

'-- config.xml //APICloud configuration

Copy the code

App object encapsulates all the functions needed for hybrid application development, but many trivial functions are hidden as far as possible, and may only need to modify a configuration to use in development, in order to simplify development. The app.openView() method, which opens a page, is one of the most commonly used methods in development, and gives you a sense of what HybridStart is made of.

First, let’s look at the API provided by the engine:

api.openWin({

Name: 'page1', // Name the window so that it can be closed by calling the close method

Url: './page1.html', // page path

PageParam: {// argument

        name: 'test'

    },

Animation: 'push', // animation effect

SubType: 'form_right' // Animation direction

});

Copy the code

OpenView () is a wrapper around this API. We hope to simplify the configuration in various ways without sacrificing functionality, so let’s start with these configurations. Let’s see how we can simplify each one.

The name attribute is used to give a window a name that can be used to call methods to operate on it in the future. If we want to omit this configuration, we can only automatically generate, but this name will be used in the future, so it can not be randomly generated, there must be a certain rule, here can be combined with the page organization to solve, according to the rules we talked about before the page is divided into two types, Level 1 page “/ view/channel/temp. HTML” and secondary page “/ view/channel/page/temp. HTML”, the law is clear, just provide the name of the page’s channel and if is secondary pages plus the name of the page, You can navigate to the page and get a unique name value from channel + “_” + page. Let’s assume that the openView method takes channel and page. Page is optional and will be called like this:

app.openView('home');           //url: "/view/home/temp.html", name: "home"



app.openView('member','set');   //url: "/view/member/set/temp.html", name: "member_set"

Copy the code

The property pageParam is a bit more complicated. Let’s talk about it later. Let’s look at animation and subType first.

These two properties should be encapsulated most. The animation type of page switching must be managed in a global configuration, and animation can be omitted when invoked. Animation direction configuration is basically a pseudo-requirement, open nature is right push, close nature is left push, respectively wrapped in the open and close page methods, subType can also be omitted.

Now look at pageParam, which is used to pass parameters to the page in Object format. Ok, this requirement must be there. We’ll make app.openView() support passing parameters, and the syntax will look like this:

app.openView(param[Object], channel[String], page[String]);

Copy the code

Because the page is optional and placed last for easy implementation, put the param parameter first. Seems to look also ok, but there will be other configuration, can not repeatedly add parameters, how to do.

There’s a experience, page and most occur in the page from the list to open the detail page, then we pass parameter is a id, which is a string, in fact, the vast majority of cases the page and is a string, need the Object is not much, based on this premise, we will extend the param parameter, You can accept both a string and an object, passing the value as an argument to the new page when you accept a string, and allowing the object to contain all the configuration of the openView method when it is an object, as well as the page parameters.

app.openView('newsID', 'news', 'detail'); // The most commonly used string parameter in real development



app.openView(null, 'home'); // If you do not need to pass the parameter, sorry, you must pass a null/undefined placeholder



App.openview ({//Object parameters must be passed this way

    param: Object

}, 'home');  



App.openview ({// Other parameters of the openView method can also be configured here

    duration: 350

}, 'home');

Copy the code

This fixes all of the problems, but there is a minor glitch: no arguments must be passed with null/undefined placeholder, because the page argument is already available, and the param argument is not valid.

There are two ways to pass parameters to the page, one is through the API provided by pageParam, the other is through localStorage across the page value, the problem of pageParam is that the new page value is slow, the value code may be like this:

// Native functionality ready callback

app.ready(function(){

    var pageParam = api.pageParam; 

// Subsequent operations based on pageParam, such as page rendering, form validation, event binding

.

});

Copy the code

App.ready () is a native function-ready callback wrapped in the framework. It is an asynchronous callback. Usually, to speed up script response, we would put operations that do not require native capabilities outside of app.Ready () and execute them synchronously. But in order to wait for the parameters to be fetched, they must also be executed in app.ready(), which is annoying.

Therefore, the frame advocates the method of parameter transmission is to use localStorage, which can be synchronized in the new page. The only problem with this method is that it may cause a waste of resources, and various parameters are put into the local, how to clean up? My method is to specify a key crossParam that will be used to pass the parameter. Each time I pass the parameter, I will put it in here, and I will erase it again and again. All that is left is the last parameter value. Json.stringfiy () is handled if the parameter is an object type, so if you pass an object, you need to do json.parse ().

// synchronize page parameters

var param = app.ls('crossParam');       

// Perform operations that do not require native capabilities

.



app.ready(function(){

// Perform operations that require native capabilities

.

})

Copy the code

Returning to the problem that the first argument of app.openView() must be filled, the point is that when app.openView() detects null/undefined it removes the crossParam key from local storage, minimizing the possibility of waste.

Of course, the official pageParam method is not obsolete, if the parameter is an object, pageParam and localStorage two methods are valid, through the api.pageparam method can also fetch the value.

With these packaging, open the grammar of the page has been very simple, but the app. OpenView () and many other functions, such as in the form of pop-up window open the page, in order to take the form of the title bar to open the page, open the new page at the same time close the current page, or open a web page, the realization of these functions are relatively complex, not a one by one, HybridStart here focuses on encapsulation ideas, but if you are interested in it, you can take a look at the HybridStart document.