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.
Related
I am planning to create a mobile app (android). It has several pages/frames for different cases. Now the number of frames/pages that I would like the app to have would grow over time, so new frames/pages would keep on adding.
Now, I have two options the way I see it. One being keep on adding new version of the app with new pages/frames once every few months. Other being I decide upfront all the possible templates for those frames. Once the templates are fixed, the response (from REST API containing data to display) would also contain the information of which template to use. I could embed the logic on how to interpret the template type available in response in the app code, so the app knows how to display a template of type "table" and what constitutes the table headers, etc.
The caveat for former approach (upgrade) is that once in while, app needs to be upgraded, something which not all users would like to do. A way around it is to enforce an upgrade, which renders app unusable. The problem with the latter approach (template) is that a lot more code needs to be written to make it work right.
I would like to know what approach is mostly used, and whether there are popular apps out there which use the latter (template) approach.
I definitely recommend using the first approach (that is, you submit updates when you actually provide new versions of the app...).
Here are a few reasons which seem to be enough to choose the regular option:
If you use the templates, you are "forcing" updates to the user. One day he has a UI, and the next he has another one (new element in the menu, or new display of a known activity/fragment). And that's worse, because he didn't receive a notification that there was a new version of the app. So he might actually get confused.
You are relying on a web connection to perform this check. So you don't even get the guarantee that this will work (depending on the permissions and business of your app, this argument may be invalid for your particular case. I wanted to answer to the general question though).
You will add a ton of complexity to your application's code (meaning no offense, I doubt you can think up-front about ALL the designs/renderings you will need in the coming months/years). And a higher complexity = more bugs, statistically.
Do you realize that the second approach you are talking about is more or less the principle of a website? Maybe what you are looking for is a simple app which has a webview to your mobile website?
I want to make an android application which will display an external message (For example: some quotes, proverbs etc) daily.
The message should be retrieved from some place other than the client device and I would like to configure the messages from back end
These messages should also change everyday.
How should the back end be and how can the android application retrieve the configured message ?
Do I need a server at the back end for the same or can avail some cloud services for the same ?
What is the best approach to do?
If you want to avoid having to set up and manage a server on the backend yourself you can take a look at a 'backend as a service' offering.
Two example candidates are:
https://parse.com
http://aws.amazon.com/lambda/
Both Parse and Amazon provide SDK's to allow you interact with the backend from your Android app.
You will likely want to study this a little to decide if you want this type of solution or to build your own server as Brian suggests - I think there are pros and cons to each approach and you'll have to choose which is best for your case.
Yes, you will need a server. You can start building the server software on the same machine as your Android emulator and create them in parallel. You'll need to choose a language and most likely a web server framework that suits your thought process and style.
If you want to use REST, for instance, google some for "best REST server framework". You will get hundreds of answers that don't mean much, but look at the communities that surround the frameworks that come back. Look at the user lists and how many questions about it exist on this site. That will give you a better idea of whether you can ask questions and get answers when they arise. You are making an investment by learning a framework, spend a little time deciding which one you are going to use, possibly by trying a few of them for a very simple site that returns the kind of data you are looking for.
Other than that, you really need to ask specific questions once you've chosen a language and a framework. Hope that helps.
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 just got done writing an Android Activity that allows other Activities to call it for some result (it's not intended to be a stand-alone Activity). I'm now working on the equivalent iOS application and can't find any resources for how I would enable similar functionality on iOS.
The situation: The tool I'm producing is intended to be used by other applications, rather than as a standalone application. The thing is, the GUI that needs to be presented to the user is rather involved so I'd like to be able to provide the developer with a "all-in-one" package that they can simply launch and get results from. Doing this in Android was very straight forward. I simply wrote an Activity and instructed the developer to launch this Activity for result. I've looked around and can't find a similar functionality to allow an iOS developer to do the same. What would be the best way to go about doing this?
I think part of the problem I'm having in finding resources is that I'm not entirely sure what what I'm making is called. A library? extension? plug-in? I would think a library doesn't have a GUI and it seems extensions and plug-ins are made for an extensible application (that is, one in which the user can install the extension/plug-in).
Your API could be à single call that would pop up a modal view. A target and selector can be specified to receive an answer. Supplying it to other developers means packing it into a "framework". I'm not sure if you can include resources.
There isn't really any equivalent. The closest you can come is having the second application call UIApplication's openURL with a custom scheme that is listened to by your app, and then when your app is done it would do the same with a custom scheme that is listened to by the calling app.
In practice, the iOS app would usually include the entire activity-equivalent as some sort of library, which at the high level would take the form of a UIViewController subclass that is presented modally and then calls a delegate method or completion selector of some sort on completion.
iPhone development is a different design than Android development, so you may need to rethink what it is you are trying to do.
Most likely you will want to look at just including the code in each program, initially, just so you can get it testable, but that may not be the best solution.
But, without knowing more details about what you are trying to do it is hard to give some suggestions as to better solutions.
For example, you may find LocalNotifications as one solution (http://useyourloaf.com/blog/2010/7/31/adding-local-notifications-with-ios-4.html), but again, it depends on what your needs are.
I found that using local notifications to call a REST service, then to process it and decide if I need to inform the user was helpful, as a replacement for how I used Intents in the Android application.
I would like to create a custom open source information management application, that I could adapt to practical needs of a psychiatrist. (and also would really like to avoid inventing the wheel). Could someone advise me what would be a good way to start? I have some amateur programming experience (see below), but I have little experience with java and eclipse (which I have set up with Android SDK plugin on my linux PC).
What I would like to achieve is a simple app where I could relatively easily re-program/rearrange information presenting screens. I would like the major development stages to be something like:
Basic framework of the app is done Main information is added
through the programming environment
basic formatting (bold, color, lists) should be supported
I imagine this would be through HTML/CSS markup Hierarchical (not
too deep) screens with concise information about conditions,
treatments; easy, not too cumbersome navigation is a must.
Possibility to attach own notes from android device
on every piece of information (e.g. on medical condition, on medication,
list of differential diagnoses, etc)
A desktop application that allows for easy adding and editing
of the content
initially could be even sqlite manager or something similar
possibility for adding images,
possibility to add rating scales, which would calculate scores
maybe also possibility to print through some android print driver
* in essence I envision this as a sort of an integrated website with a relatively simple database behind it (sqlite?) running on android. My models would be epocrates and medscape apps, but the content would be more specific to everyday psychiatric practice. It would include aspects of psychological therapies as well.
In about a years time, I think, the content would be interesting enough to see whether the app should go on the market.
My (limited) experience:
I am a MD - a Psychiatrist. I have some amateur development experience (php, html, css, Perl, bash, sed, sql, Access and some time ago - AS/400). I would like to start an app that I could modify as I go - in order to have the most useful info at my fingertips, when I need it in my work. I have considered some databases (e.g. HandDB) but my experience with them is that you get very constricted with their user interface and this hinders fast information retrieval when you need it. Adding information can be clumsy as well.
Why I am asking for help here
Most of tasks above seem pretty standard. I imagine that people with lots of programming experience here, probably would be able to point me towards some information that would help me to get started.
Many thanks for considering this :)
Are you going to develop this app? Everything you mentioned can be easily done by reading the android documentation. Although if its you doing the coding i recommend buying a book
You will find a lot of samples and other support in the android doc
Printing can be also setup using Google Cloud print
If you want to open source your application you can always use google code.
You have asked a really broad question here. But i guess the above information is good to get you started.