We're developing a prototype using MvvmCross. Eventually we'll add Xamarin to support iOS/Droid, but for now we're starting with a Win Store App.
I suspect what I'm asking is fairly obvious, but some clarification on latest best practices would be much appreciated.
Traditionally we'd build apps where there was a "frame" of some kind that held common menus, footers, etc. The "pages" of the app would be moved in and out of this frame as required. With MvvmCross we construct entirely new and separate views to match each viewmodel (at least by default). It seems wrong to me to have to copy such things as a common AppBar (in the Store App case) into each view manually. I know there are ways to manage this using "standard" Store App patterns (same on other platforms), but what is the standard, recommended (hopefully not too complex) approach people are using with MvvmCross?
Related
I'm investigating integrating Flutter into existing iOS and Android projects. My main experience is in iOS, so this post will be from an iOS perspective. But feel free to substitute UIViewController for Activity/Fragment. I'll give some background on my current understanding, and will have my actual questions at the end of the post.
Our main use case is to embed small Widgets into existing view controllers. I've gone through the Flutter docs and guides and have successfully integrated with our project (it was actually pretty easy!) but have concerns with Flutter's overall design being incompatible with our desired usage.
It seems that Flutter would ideally like to be the entire UI for an application: create and start an engine on app launch, pass the engine to a FlutterView, and make that the root view for the app. Alternatively, Flutter seems happy to own whole flows in the app where you push a fullscreen Widget which does some work, maybe pushes/pops more screens, and eventually returns control back to the native app.
However, in the case where I have a native screen with some UI components where I want to also have a flutter Widget which displays some other data - e.g. a bar graph - it seems that I need to either create separate modules, or separate #pragma(vm:entry-point) functions in my Flutter project for each type of Widget (graph, in this case) that I'd like to display.
My understanding is that each of these Widgets would also need their own Flutter engine instance which loads the proper entry point/route to that Widget's main function which then calls runApp(MyWidget).
So on to my actual questions:
What are the best practices for embedding Flutter Widgets in view controllers?
Is this correct that to have a set of small Widgets that are embedded into a view controller, I'll need to create separate engine isolates for each one?
Is this even the right way to think about using Flutter? I know there are workarounds for engine startup latency with pre-warming and caching, and I could recreate the whole screen in Flutter. But I would like to preserve our native work where I can and have Flutter be an additive change.
Can engines be efficiently reused for separate vm entry points? Would it be "weird" to have a pool of cached engines that can be used on-demand (aside from memory pressure and thread limits)?
I'm still wrapping my head around Flutter, but I've been impressed with its capabilities so far! Please let me know if I'm missing something here.
For anyone coming across this in the future, as of Oct. 21, 2020, the use case of embedding multiple Flutter widgets inside of a native UIViewController is not encouraged. Doing this in a performant manner requires updates to Flutter to better share memory and threads across engine instances.
I would like to know if someone know some Android Framework to conventional applications. For example, a framework like rails which we can see easily the MVC pattern.
See answer here for an overview of Android's limitations, which will give you an idea of why an MVC pattern on Android has not yet emerged: http://www.quora.com/Is-there-any-standard-MVC-framework-in-Android-application-development-If-not-is-it-worth-developing-one
After having posted that answer I have gone ahead and built a fully-featured app using a single-Activity architecture. It allowed us to get past all the major UX limitations that were mentioned while being able to have arbitrary complexity in controller hierarchies (parents with children with sub-children etc.). Overall it worked out great, however you WILL have to build out specialized components (ie: custom back stack mechanism) as well as to store/restore state in a way that plays nicely with Android's own Activity/Fragment lifecycle patterns. There are also certain limitations around Fragment animations which had us pull our hair out at times, which required more custom component workarounds. ie: animations that show both an outgoing and incoming Fragment on-screen at the same time aren't supported on Android, so you will have to resort to taking screenshots of views and placing them into temporary ImageViews so that you create the appearance of transitions that show two fragments at the same time. In the end it's all possible, but you will have to be ready to work around annoying Android limitations while keeping an overall MVC architecture intact.
In summary: make your top-level component an Activity which is primarily responsible for top-level navigation (tab-based, menu-based, etc., as well as back stack and state preservation). The top-level component should not govern any particular screen of your app, instead it manages controllers for every top-level screen. The controllers are all Fragments, and can contain sub-controllers which are also Fragments. All screen transitions are performed using fragment transactions as opposed to Intents/Activities. Passing around data between Fragments is another point of contention as Android generally only supports data-passing through an Activity (ie: Fragment uses its parent Activity). But in this architecture you have need to have Fragments passing data to each other (either parent/child or sibling-sibling relationships).
I don't have this wrapped up into a framework or anything, but if your dev/arch team is sufficiently proficient the architecture is definitely worthwhile shooting for. You will come out with an app that is not subject to the traditional UX limitations of Android... something that very few Android apps can say they've achieved. Also... it generally feels awesome showing you can achieve the same level of UX that iOS apps have for years. It's about time isn't it??
Don't know about the "conventional" part - Android does not play well with MVC architecture natively (mostly because Activities and Fragments take on responsibilities of both views and controllers), and I don't know if there is a standard framework for implementing MVC in Android.
I described some of my insights in more details in this answer.
That said, I created MVC (in fact MVP) template/tutorial application which demonstrates the approach I take to enforce MVP in my apps. You can use this app as tutorial, or clone/fork it and use as Android Studio template for your own apps. The source code is here: https://github.com/techyourchance/android_mvc_template
basically android has MVC pattern, but if you need more features like .net mvc you can use com.divankits.mvc module. Just see one of samples to find out how to use it.
here is more details about module:
bind properties to view(layout) objects
you are able to create field validators
convert model to json
I have many applications which has great GUI like Any.do, alarm clock from doubletwist etc. I was wondering are ll these applications developed using standard eclipse way using java and xml. I was not able to figure out how can i develop such type of GUI using eclipse xml?
All Android apps with a good UI use java & xml.
The only difference is that good apps need a LOT of work and sometimes a custom implementation of some Android Elements.
xml files catering to the different formfactors is the best way to implement a rich app (in fact I don't think there is any other valid way) :
-They allow you to separate the layouts from the code as much as possible.
-They allow you to treat specific form factors independently.
Additionally, Great apps often re-implements some of the basic UI elements. For exemple the implementation of the actionbar in Flipboard allow them to apply their flipping effect to it, something that you cannot do with the basic ActionBar.
Any.do has just been updated and I have not checked this last version yet, but the last time I tried the app, their implementation was not really good. Buttons were far too cramped in the ActionBar and their custom ActionBar was very slow (more than 1 second to acknowledge a tap).
Additional thoughts : sometimes these beautifully designed apps tend to ignore at least some of the Android conventions. It is a really bad idea : you can create a very beautiful app but if its UI elements are totally different from what users encounters in other Android apps it will just make the overall use of the app confusing. imho the best way to create a great app (both visually & functionally) is to use Holo as a design base that needs to be enriched and do not :
-make something totally opposite to the design conventions of the platform just because you think it is good.
-Use a basic android design block in a totally different way that what it is intended for, it will utterly confuse your users.
-Apply another platform conventions.
-Invent your own rules because "you are strenghtening your brand by having the same design on ios, android and your website". You are just being lazy.
a good starting point is obviously the official design site. android niceties is a good source of inspiration. Holo Everywhere & Android UI UX are very interesting sites in order to get more thoughts on how to improve existing apps.
I've been coding for my Android phone lately, and i've been wondering... is this Intent class supposed to outline a new programming style?
I've been suspecting the API design discourages MVC: Intents are the main way to interact with all user-related objects (Activities, Services, Other apps...).
Is my train of thought right? Should is stick to "contaminating" Activities with business logic?
I have been reading the android developers site and no particular coding style is encouraged though.
Your question isn't entirely clear, because you seem to be confusing coding style with program architecture.
In my mind, Android really changes nothing in terms of coding style. Your coding style from Java will still work fine, and most Android apps look very similar to other apps. In the abstract, there are some things that you might want to do in Android you don't do as much in other languages, see the Android guide for details. The basic idea is: memory is limited, don't use it if you don't have to.
As far as whole program architecture goes, yes, the Android style is highly based around the message passing (through Intent objects) style. The way you react to GUI events within an Activity is still largely the same: you use event handlers to react to events like button presses, etc... But the platform is strongly centered around designing apps using different components (Activities, Services, BroadcastReceivers, etc...) and Intents to communicate between them. While Intents provide a flexible way of exchanging data between components, you still shouldn't be passing massive amounts of data within Intents, instead you should put those kinds of things in a ContentProvider or something similar.
I took a lot of the following ideas I took from this OReilly book. This is just whats worked best for me.
As far as architecture goes, its helped me to think of Android's UI as a Page Controller pattern - I found it to be similar to .Net Web Forms actually. So yes, it does fit with MVC (at least the Page Controller flavor of it). An Activity is your controller, you typically store your view in XML, and you can build out your Model however you like.
You see a lot of web-ish ideas in Android. Intents are a lot like HTTP, or more generally REST. Intents have a 'noun' that says what they are concerned with (can be explicit class declaration ie: go to a specific Activity, or can be more implicit using Intent Filters), the Action is a lot like an HTTP verb (Get, Post, etc), a Bundle is a lot like a list of query string parameters or payload...etc.
And similar to a web page, you want an Activity to be able to take care of itself. What I mean is, you don't want to pass around some big serialized object from activity to activity, its a lot cleaner/resilient/reliable to just pass the id of the a given record to the next Activity and let that activity grab the record with that id from the db (ContentProvider, some other persistent source...). Activities are also meant to be loosely coupled, and you're supposed to be able to navigate to one from various paths, it also makes them more re-usable. Thus, allowing the callers of an Activity to simply provide a recordId is a lot easier then the Activity expecting its consumer to have provided a large serialized object.
Bottom line - no, you don't need to contaminate Activities with Business Logic, tuck that stuff away in an application layer, or a gateway or something like that. As for persistence, the ContentProvider interface is pretty well designed - I like it alot. It also continues the Android RESTful theme, accessing content via URLs and verbs (query, delete, update, insert).
Sending and receiving intends is much like sending and registering (similar to a publish-subscribe channel) for command messages (e.g. in a distributed enterprise application, and this is about architecture, not style). This pattern helps designing a loosely coupled system of interacting applications.
I cannot remember having seen a similar architecture before used for the interaction of components and applications on a single computer but it helps to design application using other applications to easily build an ecosystem of features/components.
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.
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.
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.
You might want to take a look at subclassing ActivityGroup for your top-level activity. That can host multiple sub-activities. TabActivity, the only stock subclass of ActivityGroup, is perhaps not what you need because it includes a tab widget, but you can use it as inspiration for what you do need.
What specific headaches are you having with a single-activity architecture? Perhaps there are ways to make that less painful.
In general, if you are aiming to have native apps with a native look and feel, it is not reasonable to have a single UI design for all three platforms. The UI guidelines and user expectations for the systems are different, and those differences should be reflected in the UI designs.
If you really want to have a single UI for all platforms, just create a web app instead.
I'm not sure exactly what you mean by an "animation centric" design with seamless state changes. If you use multiple Activities, Android will animate between them in a way that Android users will expect. If you explain what exactly you are trying to accomplish, we can help you figure out if it makes sense in Android, and if so how to accomplish it.