Menu
I will try to keep this short, but I need some advice.
I work on a team that is developing applications for android, iphone, and wp7 in parallel. We have a design team that comes up with a single design for all three platforms.
The latest application’s design is more marketing than productivity. The original POC for this app was done on the iphone. The design is very animation centric and most state changes are seamless (things will animate on and off the screen during state transitions).
If I keep developing against this design it means I will have to have everything in a single activity. So far, this has been a major headache. To my knowledge, dividing your application into activities is almost required. I could try to dynamically load and unload views as I change states but this doesn’t seem right.
I see where the design team is coming from where they want all these state changes to be seamless, but I don’t think this is right for android.
I would like to know what makes most sense. Should the design change to incorporate multiple activities or would it be worth trying to make this work.
883
This pattern defends that instead of using an activity for each screen, the app is built with a single activity that works as a container for fragments that will be replaced for each screen, and manage through a stack. The core idea is to change the activities for fragments.
An activity provides the window in which the app draws its UI. This window typically fills the screen, but may be smaller than the screen and float on top of other windows. Generally, one activity implements one screen in an app.
If we use Single Activity Architecture, the sharing of the data happens in the Fragments level and all of the Fragments are wrapped inside the Activity. Doing this keeps the shared data away from other elements in the Application Scope which means it cannot be accessed by Service or Content Provider.
The Compose application is designed to be used in a single-activity architecture with no fragments. You can still have multiple activities or fragments and use setContent in each of them, but in this case the transfer of data between activities falls on your shoulders.
We have a design team that comes up with a single design for all three platforms.
That's akin to coming up with a single floor plan to be applied to apartments, single family homes, and warehouses. The designers, or management, need to have their heads examined.
The latest application’s design is more marketing than productivity.
Did I mention that the designers, or management, need to have their heads examined?
If I keep developing against this design it means I will have to have everything in a single activity.
If I am interpreting your requirements correctly, that is probably accurate. While you can arrange for animations between activities, it is more of a "slide the old off, slide the new on", and I suspect that your requirements exceed that.
To my knowledge, dividing your application into activities is almost required.
It is certainly Android's intended development model for ordinary apps. However, games and the like may not follow this pattern, and you don't have to either.
I could try to dynamically load and unload views as I change states but this doesn’t seem right.
Depending on how many states there are, you might just hang onto all of them, recycling as you go.
93
I am surprised no one mentioned fragments which can be used instead of activities at many places.
Fragments can be seamlessly animated in and out or an activity.
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
