Comparison between j2s and Android-[mobile development]

 

I. Program Portal
The entrance class of the program is MIDlet. All the programs of the program must inherit this class to initialize the program. The Android program Portal is an Activity class. Next let's take a look at their lifecycles.

J2-midlet Lifecycle
1. When the startApp (active state) program starts, this method is called to initialize the resources required by the user.
2. PauseApp (paused) this API is called when a phone call receives a call. You can call this interface to stop or write operations on the thread.
3. called when the destroyApp (destruction status) program exits. You can call this interface to process active threads.
The conversion can be called by AMS or by program code. The result of the resumeRequest call is that AMS will call the startApp method. The result of the yypaused call is that AMS may call PsuseApp. The notifyDestroyed call will destroy the midlet.

Android Activity Lifecycle
1. This interface is called when the onCreate program starts initialization. This interface is also called when the user navigation returns to Activity. It is similar to multiple Canvase (Displayable) switches in j2s. Therefore, the Activity is similar to Displayable.
2. After onStart onCreate is called, the program calls this interface.
3. onResume onStart calls this interface. At this time, the Activity enters the running status.
4. onPause calls this interface when a new Activity is started.
5. onStop is called when the Activity is invisible.
6. called when the onDestroy program is destroyed.

Ii. display components
The Displayable and Canvas components directly or indirectly inherit from the Displayable components in j2s. Different inheritance leads to the difference between low-level UI and advanced UI. All ready-made UI components in j2s directly or indirectly inherit Screen. You only need to call Display. getDisplay (MIDLet instan). setCurrrent (Displayable disp) to Display the component on the mobile phone interface. You can also use this interface when switching the interface.

Android-visible components directly or indirectly inherit android. view. View. Activity. setContentView (View view) can be displayed on the android mobile phone interface. You can also use this interface when switching the interface. If the View is inherited directly, instead of the UI component provided by Android, you must refresh it yourself, similar to the low-level UI component of j2-based.

3. UI
The high-level UI component is refreshed inside the component. The low-level UI can be refreshed through the repain () of the Canvas. The low-level UI architecture can be implemented using the MVC method. We recommend that you use the second-level cache. Android provides the onLayout interface to provide this View to adjust the layout of component elements in it. You only need to override this interface and then OK. Refresh interface onDraw, which is used to refresh the drawing elements in the interface. This interface is similar to the painting interface of the j2_canvas. However, the parameters passed by the two platforms have some meanings. Graphics is used for the upload of j2-based data, while Canvas is used for android. When Android draws the image, a Paint parameter is input. This object indicates the painting style, such as color, font size, and font format. If it is a transplant, we recommend that android also use level-2 cache, which is easy to manage.

If you read the API, we can find that the repaint () method of Canvas in j2s implements the same function as the invalidate ()/postInvalidate () method of View in Android, but invalidate () /postInvalidate () is different: invalidate () can only be updated on the screen by calling onDraw (Canvas canvas) in the UI thread, while postInvalidate () it is necessary to do the same thing in the non-UI thread. This requires us to determine which call is in the current thread and which is not. This is especially important in multi-thread callback. In j2s, you can directly call repaint.

In addition, the display of the View class of Android is largely read from XML, including its layout and many attributes. We will discuss how to read it later. The Canvas only needs DRAM Draw, and the Canvas cannot be set to the size (the fullScreenMode is not required), but the View can.

View constructor, we do not need to call in Activity, but Displayable is required. In the Activity, we need to use findViewById to retrieve the View from the XML, and then forcibly convert it to the child type of the View, while the Canvas of j2_9 must be constructed.

Perhaps in UI applications, Android is more powerful than j2's, because its View has many defined sub-classes that can be called conveniently and beautifully. Because Android is open-source, many third-party controls will be available for us in the future, which greatly expands Android. This frees us from those graphics. drawXXX functions and makes our applications cool and cool.

Iv. User event handling
In j2s, Canvas can respond to buttons and touch screen events. It encapsulates six protected methods and responds to six different events: keyPressed (int keyCode) used to respond to button press, keyReleased (int keyCode) is used to respond to button Press Release, keyRepeated (int keyCode) is used to respond to button press for a long time do not release; pointerDragged (int x, int y) used for responding to touch screen dragging, pointerPressed (int x, int y) for responding to touch screen clicking, and pointerReleased (int x, int y) for responding to touch screen releasing. In terms of parameters, keyCode tells us which button triggers the event, and x and y tell us the coordinates (absolute position) when the touch screen is clicked ).

In Android, View can also respond to the preceding two types of events: boolean onKeyDown (int keyCode, KeyEvent event) for responding to button clicks, boolean onKeyMultiple (int keyCode, int repeatCount, keyEvent) is used to respond to repeated clicks of buttons, boolean onKeyUp (int keyCode, KeyEvent event) is used to respond to button release, and onTouchEvent (MotionEvent event) is used to respond to touch screen events. The official API indicates that the onKeyMultiple method always returns false, that is, it does not have a handle, so it must be rewritten for implementation.

In terms of Keyboard Events, the difference between J2EE and Android is that Android defines the KeyEvent class to describe key events. This KeyEvent is not simple. It can fully describe a key event. Its getAction () method can get the down, up or multiple actions of buttons; its getDownTime () can get the time when the last keyDown event occurred; its getEventTime () you can get the time when this event occurred; its getRepeatCount () can get the number of consecutive clicks on the same key (this is largely designed for the onKeyMultiple method ). One thing to note is that when the Android underlying layer triggers the keyDown event, one thing is quite different from the one in the j2's: for example, if we press a key but do not release it, The j2's only trigger one keyDown event by keyPressed () run the command and then hand it over to keyRepeated () for processing. However, Android is triggered every several times (dozens of milliseconds). The onKeyDown method will continuously respond to events, causing unexpected events. It is not difficult to solve this problem. You can use getAction to determine whether the event is keyDown. If so, use getEventTime () to subtract getDownTime (). If the value is too small, you can choose not to respond. This method is simple, but if the user input is too fast, the real input may be ignored, so there is another way: maintain a stack and rewrite onKeyDown () and onKeyUp () when the method is used, if getAction () is keyDown, it is written into the stack. If it is keyUp, It is thrown out of the stack. If an event is generated, when it is keyDown, if the current top of the stack is keyDown, you will choose not to respond to this event. In this way, a long click is equivalent to a single click. In fact, there are some view subclasses. For example, if the Button is added to the onLongClick () processing method, even if you select this view and press the selection key for a long time, you can also process it accordingly.

In terms of touch screen, Android only processes onTouchEvent (). However, because its parameters contain MotionEvent, the three events separated under j2s can be distinguished by the getAction () method of MotionEvent. What is interesting is that the MotionEvent has a getPressure () method that can obtain the click pressure. It seems that the Android mobile phone has a high degree of precision in components, even the software can obtain the pressure and use it to make some logic.

In addition, the KeyEvent and MotionEvent of Android can be self-constructed. The KeyEvent can pass itself to the Callback of the KeyEvent through the dispatch () method, that is, the Event Response Processing Method, in this way, we can make a soft keyboard and do many other things.

V. Database
The difference between them is that android sqlite can easily establish the association before the table to the table, while J2EE must implement its own framework, and ANDROID sqlite provides some interfaces (such as SQLiteOpenHelper ), it is very easy to develop databases. In this case, you can read and write serialized data in a file, while in android, you only need some SQL statements.

This article is from "simayilong"