How can I control life cycle of QML forms (I mean windows)? I am talking about onCreate, onResume, onPause etc. methods on Android or life cycle of views on iOS. And Can I work this life cycle of QML forms on Android, iOS, Windows 10 Mobile, desktop etc.?
Design of Qt Quick (QML) applications is different from Android ones. There is no difference between views and objects like Button, Text, etc. Every QML object with graphical representation inherits Item and it is possible to define Component.onCompleted and Component.onDestruction functions. They will be executed once object is created and destroyed. If you also need a pause signal I suggest creating functions pause() and resume() in every view you create and create an object that will manage the views - create, destroy, pause and resume them.
Please notice that you need to take care of transitions between views and states yourself. Also as you can create your own QML objects it is worth considering creating a template of a view and then only inherit it.
This will work with every system you deploy the app on.
If you have more questions, need example etc. consider editing the question or leaving a comment.
I want to thank BaCaRoZzo once again for useful tips. I added them to this answer.
I have created an example project that tries to mimic Android app life cycle. This will work with every OS. This is just an example but I think that similar approach may be used in release source. However, first you need to understand the nature of the QML. This is high level language that is already being managed by some other process. It is far different from Java. For example take a look at the fragment of the docs about a state used by background processes:
A Qt Quick application should not usually handle this state at the QML
level. Instead, you should unload the entire UI and reload the QML
files whenever the application becomes active again.
So if I were you I would only save sensitive data when I detect application is going to background. No need to try and unlod views etc. It would be needless uphill struggle becuase QML is not designed for this. Instead let your app be killed if OS needs more memory.
You can find the example project here. You can use it if you want. It contains comments to let you better understand what is going on.
Related
I have a very simple app which runs great on the PC, but runs 'acceptably' –not by much though- on my tablet (Samsung Galaxy Tab 3, SM-T210). It’s a very simple app so I thought that it would have ran great from day one, but it didn’t. I’ve seen some really resourceful applications –mine cannot even compare to them- running very fast and smoothly on a tablet. So I’ve been wondering how to accomplish that.
I’ve heard that you can accelerate your flex application using Stage3D, Starling or Feathers. I think with most frameworks I would have to rewrite part of my app because I would have to use the framework’s components to make the app run faster. I don’t know if I’m correct by this though. Is this correct?
Is there a way to accelerate my Flex Mobile app using one of those frameworks without having to rewrite a substantial part of my code? If so, can you tell me how?
Thanks in advance for your help.
Regards,
Sebastián
NEEDED FOR SOLUTION
Every tip that Rod stated is very important. It will improve the performance of a well-constructed application and make it run smoothly. The problem with those tips is that they are the smaller “half” of the iceberg and not the bigger “half”.
My application was transitioning very slowly from one View to another and this was due to the fact that I wasn’t “respecting” the Flex’s component Lifecycle. What I mean by this is that I was performing operations of configuration of the components after they were added to the DisplayList of the View and were validated. Also, I was adding children to the view programmatically after the method INITIALIZED event was fired. This made the View take more time to recalculate its children’s properties and add some more components to its DisplayList even after that part of the its lifecycle was supposed to be done. This made it take more time to render to its final state, hence, interrupting the transition from View to View. What I needed to do was to configure the components before they were added to the DisplayList and add more components to the View before createChildren() method was done.
The best and first advice, at least from my experience, to reach a “normal” performance is to abide by the guidelines of the lifecycle. Respect the construction, configuration, attachment and initialization parts of the process and you’ll be fine. If you don’t do this, all of the advices mentioned by Rod won’t be useful to get your application to perform smoothly.
It is true that only by abiding by the lifecycle you won’t be able to get your app to the best performance. For that, you’ll definitely need the advice mentioned before, but these tips are, what I call, the second part of the iceberg. First things first, code following the guidelines of the components’ lifecycle; second, follow all of Rod’s tips. With these two you’ll have a fast-as-lightening running app.
In my Flex-Mobile app, I haven't tried using any frameworks. In order to optimize my application, I am doing the following tips:
write item renderers on AS
subclass LabelItemRenderer or IconItemRenderer
avoid complex bindings
set autoDrawbackground to off
Use BitmapImage over Spark Image
use PNGs over JPEG or GIF. it takes less image decoding and rendering time
Text - Use StyleableTextfield (can be use only in AS)
write skins in AS (extend MobileSkin)
write custom component in AS3 not in MXML
setElementSize is cheaper than setting width and height
setElementPosition is cheaper than setting x and y properties
use light-weight components (i.e. Label)
use cacheAsBitmap property
components that are not changing frequently but are redrawn often
can be cached as Bitmap to optimize rendering time
don't use BorderContainer, use Group + Rect
reduce number of nested Groups
use Scroller.viewport instead of Scroller.verticalScrollbar
Do you have Lists in your app? You could rewrite ItemRenderers etc.
Every tip that Rod stated is very important. It will improve the performance of a well-constructed application and make it run smoothly. The problem with those tips is that they are the smaller “half” of the iceberg and not the bigger “half”.
My application was transitioning very slowly from one View to another and this was due to the fact that I wasn’t “respecting” the Flex’s component Lifecycle. What I mean by this is that I was performing operations of configuration of the components after they were added to the DisplayList of the View and were validated. Also, I was adding children to the view programmatically after the method INITIALIZED event was fired. This made the View take more time to recalculate its children’s properties and add some more components to its DisplayList even after that part of the its lifecycle was supposed to be done. This made it take more time to render to its final state, hence, interrupting the transition from View to View. What I needed to do was to configure the components before they were added to the DisplayList and add more components to the View before createChildren() method was done.
The best and first advice, at least from my experience, to reach a “normal” performance is to abide by the guidelines of the lifecycle. Respect the construction, configuration, attachment and initialization parts of the process and you’ll be fine. If you don’t do this, all of the advices mentioned by Rod won’t be useful to get your application to perform smoothly.
It is true that only by abiding by the lifecycle you won’t be able to get your app to the best performance. For that, you’ll definitely need the advice mentioned before, but these tips are, what I call, the second part of the iceberg. First things first, code following the guidelines of the components’ lifecycle; second, follow all of Rod’s tips. With these two you’ll have a fast-as-lightening running app.
What is the best way to avoid having lots of code in the main.java file when writing android apps.
it seems i will have to switch the views constantly all running through the main java file and having worker services fireing events.
am i missing something or is this how it is meant to work?
Without more information, this is unanswerable.
The best advice now is to read the android dev guide. There is a section of best practices. You can take a look at: http://developer.android.com/guide/practices/ui_guidelines/activity_task_design.html and http://developer.android.com/guide/practices/design/performance.html
Think about putting some code in separate threads also: http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html
It's hard to understand what you mean by services firing events. The android UI is meant to be coded as objects receiving and dispatching events, and the app should respond to those evens accordingly.
Depends what kind of app you have.
Normally, different "screens" are handled by separate Activities. Activities normally handle user input and take part in history stack (handling moving forward/back between activities and apps).
Views in Android are classes responsible for rendering parts of the screen. ViewGroups contain Views (and other ViewGroups) and are the basics of view hierarchy. View hierarchies are usually defined declaratively via XML, no coding required.
Services are code that run in the background without UI.
Recommended programming model is to program asynchronously: register handlers and code will be called when events happen. This is used not only for UI, but also for broadcasts, gps, alarms, data download, sync manager, notifications, etc..
So, Android apps are usually quite short - a 1000 lines app can already do quite a lot. Also, they tend to be nicely partitioned into distinct classes.
What considerations should one be mindful of when constructing a GLSurfaceView-centric UI?
This is for a game and the bulk of the UI will be an intro screen (start, options, about, exit) and a level selector screen. I've put a lot of time into the rendering/animation for the game using OpenGL, and I'm no graphic artist, so taking the OGL UI route seems to make sense to me. But I'm an Android novice and need some outside input. Thanks for reading.
There is nothing wrong with that, especially for a game. The only problem is that you will have to do everything yourself. Most games seem to be doing this.
Due to the ease from which one activity can start another, I would say it is worthwhile to abstract your options and level selection from the game itself. If you're unfamiliar with starting activities and/or passing information between activities, there are plently of good tutorials and examples to help. You could try the ubiquitous Notepad tutorial if you haven't already ( http://developer.android.com/resources/tutorials/notepad/index.html ).
The advantages of this method would be to leave your OpenGL/game Activity less cluttered, and that you would be able to use tried-and-true Android UI elements instead of building your own from scratch.
This pattern is similar to the pattern Main Servlet (the Front Controller) that is used for developing web applications.
The main idea of this pattern: we have one Activity that manages multiple views and this activity is responsible for representing current content. Not all views need functional of activity (e.g. life-cycle methods) so the main question is: if I can go without activity why do I have to use it?
I have found the following disadvantages of using this pattern:
Official source doesn't recommend to Overload a Single Activity Screen
but they don't explain why.
We cannot use TabActivity, ListActivity, MapActivity. But there are some tricks to go without them.
If different screens have different menu it's a problem to make that without activities.
It is necessary to keep history by ourselves. But it's not so difficult to develop.
I have found the following advantages of using this pattern:
It's faster to change the content of current activity than to start another activity
We are free to manage history as we want
If we have only one activity-context it's simpler to find and solve problems with memory leaks
What do you think about this pattern ? Could you provide any other advantages/disadvantages ?
We cannot use TabActivity, ListAcivity, MapActivity. But there are some tricks to go without them.
You have to use MapActivity if you want to use MapView. You have to use PreferenceActivity if you want to use preference XML.
It is necessary to keep history by ourselves. But it's not so difficult to develop.
The difficulty in managing your own history will depend greatly on what the history needs to be. Implementing history for a simple wizard will be fairly easy. However, that is a particularly simple scenario. There is a fair amount of history management code in Android that you would have to rewrite for arbitrary other cases.
You also forgot:
#5. You will be prone to leak memory, because you will forget to clean up stuff, and Android will not clean up stuff (since it assumes that you will be using many small activities, the way they recommend).
#6. Your state management for configuration changes (rotation, dock, SIM change, locale change, multiple displays, font scale) will be more complicated because now you also have to figure out what extra stuff (e.g., history) need to be part of the state, and you have deal with all of them at once rather than activity-at-a-time.
#7. Having multiple entry points for your application becomes more challenging (e.g., multiple icons in launcher, app widget linking to some activity other than the main one, responding to etc.).
It's faster to change the content of current activity than to start another activity
For most modern Android devices, the speed difference will not be significant to most users, IMHO.
If we have only one activity-context it's simpler to find and solve problems with memory leaks
Except that you still have more than "one activity-context". Remember: your activity, large or small, is still destroyed and recreated on configuration changes.
What do you think about this pattern ?
Coase's "nature of the firm" theory says that businesses expand until the transaction costs for doing things internally become higher than the transaction costs for having other firms do the same things.
Murphy's "nature of the activity" theory says that the activity expands until the transaction costs of doing things internally become higher than the transaction costs for having other activities do the same things. Android developers will tend towards a "user transaction" model for activities -- things that are tightly coupled (e.g., steps in a wizard) will tend to be handled in single activity, and things that have little relationship (e.g., browse vs. search vs. settings vs. help vs. about) will tend to be handled in distinct activities.
This will be horrible to maintain if new functionality is added later on.
I'm also not convinced it will be so much faster that the user could notice.
Having components as smaller pieces that are easier to change or swap out is definitely the way to go.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I was a JaveEE developer. Recently I joined an Android development team. The structure of Android confused me. The MVC design pattern doesn't seem to suit for Android development. So what is the design pattern principle for Android development? I mean is there any hint about how to write a clean, easy reading and effective Android code.
Android's architecture annoyed me at first, but I beginning to see a method to their madness. It's poorly explained by the android documentation. My biggest gripe has always been that it's hard to have a centralized data model with objects that your Activities share just like a normal application. Android seemed to want me to be a nomad because I could only share primitives between my Activities. And dropping junk in a database is NOT a model because it contains no behavior. So as most people my business logic all ends up in my activity making it hard to share business logic in other activities.
I've come to find out I was missing some key puzzle pieces. Android is MVC. However, it's coupled to the View fairly heavily.
Activity == Controller
Model == Subclass of Application
Anything that subclasses View == View
Interestingly you can create a subclass of Application and declare this in your Manifest file, and Android will create a single instance of this object that lives the length of your application no matter what Activity is destroyed or created. That means you can build a centralized data model there that all Activities have access to.
The way I see this is something like a primitive Spring container that you can initialize objects and resolve dependencies between them. That way you can decouple the model portion of your application away from the Activity themselves. And just have the Activity make calls on the model, and hand callbacks to receive the results so it can update the UI.
The problems with Android is that it mixes controller and view pretty heavily. For example, subclasses like TabActivity, ListActivity imply a certain view being used. So swapping out a view is pretty involved. Also the Controller makes very specific assumptions about what the view is even if you use Activity. He contains direct references to UI objects like TextView, etc. And it registers for low level events like clicks, keyboard, etc.
It would be better if Activity could register for more high level events like "Login", "Update Account Balance", etc which the view would dispatch in response to a series of clicks, keyboard, touch events. That way the controller works at the level you might describe features instead of design features.
I think we'll reach this type of design eventually as we better understand come up with better tools and techniques. It seems like Android might have the extensibility to make this happen, but it's up to community to chart it.
The actions, views and activies in Android are the baked in way of working with the Android UI and are an implementation of a model-view-viewmodel pattern, which is structurally similar (in the same family as) model view controller.
To the best of my knoweledge, there is no way to break out of this model. It can probably be done, but you would likely lose all the benefit that the existing model has, and have to rewrite your own UI layer to make it work.
You can find MVC in the followings:
You define your user interface in various XML files by resolution/hardware etc.
You define your resources in various XML files by locale etc.
You store data in SQLite or your custom data in /assets/ folder, read more about resources and assets
You extend clases like ListActivity, TabActivity and make use of the XML file by inflaters
You can create as many classes as you wish for your model, and have your own packages, that will act as a structure
A lot of Utils have been already written for you. DatabaseUtils, Html,
There is no single MVC Pattern you could obey to. MVC just states more or less that you shouldn't mingle data and view, so that e.g. views are responsible for holding data or classes which are processing data are directly affecting the view.
But nevertheless, the way Android deals with classes and resources, you're sometimes even forced to follow the MVC pattern. More complicated in my opinion are the activites which are responsible sometimes for the view but nevertheless act as an controller in the same time.
If you define your views and layouts in the xml files, load your resources from the res folder, and if you avoid more or less to mingle this things in your code, then you're anyway following a MVC pattern.
Android development is primarily GUI development, which like Swing/AWT in Java consists of lots of anonymous inner classes reacting to GUI events. Its one of the things that has really kept me away from doing a lot with Swing....but I have an Android phone, so I'm going to grit my teeth and just get over it, as many an Apple fanboy has said about the antenna problems. ;)
Android makes the typical decision of making the Controller and the View a single class. This encourages putting too much in the same place. An Activity corresponds to a screen, each View to a region of a screen (sometimes the whole screen), each Controller to the user gestures from that region of the screen, and Models are just Models, sometimes backed by services from Environment or some other crazy little set of utility functions. I use the Activity to coordinate one or more MVC trios. This helps deal with Android's choice to just throw everything in the same place.
I can test the vast majority of an Android app without running the simulator. Big win.
Sorry for my English.
Android has a very good modularity (Activities, Fragments, Views, Services, etc.). So there is no need in MVC.
Of course there is the separation of taking input (Activities, Fragments), logic, view (xml or java) and data (databases, files, preferences). But this is not MVC. You shouldn't try to use MVC, it will only complicate your architecture.
Rather than keeping something in global scope, Android motivates you to keep objects as deep as possible in their scopes (class members, local variables), and pass objects to/from activities, or to fragments, using Intents/Bundles. This is also because of memory limitation.
The system may destroy your activity if the foreground activity
requires more resources so the system must shut down background
processes to recover memory.
So it's not safe to store not-constant (mutable) objects as global (static) objects. Usually you use static for immutable constants.
In simple terms, you separate your application into screens (Activities). Then each screen - into fragments (Fragments). To perform a sequence of actions on the screen you can also separate them using Fragments (example).
So you have very small blocks in your application, each of which you can easily test and reuse.
My impression is that android programming model has lots of similarity with MS WPF.
XML layout definitions, code that is always bound to one of these definitions...
So, if you are asking about design patterns because you want to improve your current or in development android projects, maybe you should look at WPF practices and patterns for improved architecture, like MVVM.
Check out these links:
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
there is small project that is already trying similar thing:
http://code.google.com/p/android-binding/
cheers