I am thinking about using mvvmcross in one of the projects. For now I am just exploring the mvvmcross and going through different articles, but I cannot find anything relating to mvvmcross and android service. How to start, stop or bind to service in view-model. What is the "best" approach when dealing with services? Does anybody has a link or anything on the subject.
Uros
In general I treat Android services, ios long running tasks and Windows background tasks as separate 'services' and they don't generally interact directly with the ViewModels, but instead interact via messaging, via data stores, etc. Specifically for Android, you may need to use View/Activity level hooks like service local binding (see Android - Service and Activity interaction)
When the background services share the same process (same memory space) as the ViewModels, then one thing that can seem a little awkward is initialising shared IoC and any required application singletons. However, generally this doesn't seem to be too hard to do - e.g. see questions like Using MvvmCross from content providers and activities and MvvmCross initialization
I haven't personally seen enough examples of this type of app to work out if there's a few common architectural patterns that could be supplied at an mvvm-platform level. I'd love to see more examples and more people talking about architectural ideas in this area.
Related
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'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 want to develop an application that supports plugins and that provides data to these plugins. It seems to me that the correct way to implement this plugin-archtitecture on Android would be one apk for the main app and one apk per plugin.
But as the main app and every plugin are in different apks I can't easily pass (data) objects from the one to the other, the applications run in different processes and even if they run in one process (which can be achieved) they have different classloaders and this doesn't work. Currently I see two promising approaches for getting data from my main app to my plugins:
Declaring the main app as a ContentProvider. This seems to me to be the intended approach because it does exactly what I want to achieve: providing content/data to another process.
Making my data objects Parcelable and pushing them around with AIDL or - if I do not need multithreading - with the Messenger-approach. In my opinion, this approach seems to be easier because I can use an ORM-library which cares about the Database in the background. I never used ContentProviders before but at a first look at it I thought that using a ContentProvider is a bit like building SQL-Queries by hand (please tell me if I'm wrong), and I would like to avoid that work!
Now I would like to know if I missed any pros or cons and if there are notable performance differences between these two approaches. And which solution would you prefer and why would you do so?
Thanks in advance! Any replies are appreciated!
Content provider is just way to share data (that are stored in different ways [database, files and so on]) between applications. If you want just share data between application it is the best way to do this.
However, if you want services to perform some tasks with data (for instance, sum several values provided by you) it's better to have a remote service.
In general case, application - plugin interaction is more similar to a remote service. In this case the main application exposes a remote service (an API of this application) that can be used by plugins to perform some actions.
I have seen applications with add-on modules on market - these modules add-up some new functionality.
What would be the best way to do that ?
I cannot think of a descent and neat way to do that.
There are many ways. The most common is to just install another application and access it via Intents. It's definitely worth looking at Open Intents. If you are really adventurous, you can even load custom plugins with DexClassLoader.
IMHO the only way to cleanly implement this is to use Android's build-in extensibility, namely by using Intents and/or BroadcastReceivers. This is the way Android apps are supposed to communicate with each other, but it may work perfectly also for your own app by creating a main version which is extensible through Intents by your "plug-ins" which can be downloaded separately from the market.
The things you need to learn about and look for on the web to implement such functionality are
Intents: Learn how you can use intents to pass data from one app to another or to invoke certain functionality on other apps.
BroadcastReceiver: For listening to certain events broadcasted by your app in your "plug-ins"
ContentProvider: The content provider is used to provide an abstraction over your data and allows your "plug-ins" to access your app data easily and nicely decoupled through Content URIs.
Intent Filters: These are used to tell the system which kind of actions/Intents my specific Activity is able to accept. You will need them as a way for invoking your plug-ins (by broadcasting an Intent with the given action/category) as well as for providing a space in your menus where "compatible" Intents may hook in automatically.
I hope I was able to provide you some of the topics you need to know about. I'm sure that once you get a deeper understanding on these, you will get a much clearer picture on how to realize such a modular app.
it's been some time now, since I started reading about android.
I've already made a few basic applications, but I still miss something: How is actually sharing application component being done?
This is what the Android Dev Guide says:
A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). For example, if your application needs to display a scrolling list of images and another application has developed a suitable scroller and made it available to others, you can call upon that scroller to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application or link to it. Rather, it simply starts up that piece of the other application when the need arises.
I think I came across some question like this, but I think I'm still confused.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Is information about the data that the application operates with private, too?
If it is described in the AndroidManifest.xml file is it available for the other applications, or it is available only to Android?
When I started satisfying my interest in Android - one of the things that grabbed me was the impression of immense interoperability...
:)
Have I been wrong or I still haven't found the way?
Thanks!
How is actually sharing application component being done?
That depends entirely on what you consider an "application component" to be, and what you consider "sharing" to be.
This is what the Android Dev Guide says
That is a fairly bad piece of the documentation. Here is how I would write it:
A central feature of Android is that one application can make use of components (e.g., activities, services) of other applications (provided those applications permit it). For example, if your application needs to display a list of contacts and another application has developed an activity that does just that and made it available to others, you can call upon that activity to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application. Rather, it simply starts up that piece of the other application when the need arises.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Either developers are intending for you to integrate with them, or they are not. If they are, they should be documenting how to do that (e.g., Intent formats to be used with startActivity() to trigger their code). If they do not document such integration points, you can certainly ask the developers to add some. However, randomly shooting Intents at them in hopes of getting a response, even if it temporarily works, is little better than script kiddie tactics -- those developers are not obligated to ensure you code works when they upgrade their app.
Is information about the data that the application operates with private, too?
I do not know what "information about the data that the application operates with" means. Data managed by an application is private by default. Again, application developers can offer integration points for data (e.g., content provider, remote service API) -- some do, some do not.
one of the things that grabbed me was the impression of immense interoperability
Android offers greater interoperability potential than some other mobile platforms. However, using that potential requires consent among the interoper-ees. You cannot unilaterally decide to hack into another app's database, or invoke private activities, just because you feel like it.
Should more Android developers offer more integration points? In the abstract, sure. However, bear in mind that this adds support costs (e.g., answering integration questions) and limits coding flexibility (e.g., need to maintain a stable API for those doing the integrating). Developers cannot be blamed if they do not wish to incur all that.