I want to create an android game and I want to divide it on 3 layers. First layer is authentication layer with CustomAuthenticator visible in Settings->Accounts & Synch, second layer is a list of existing games or existings rooms and third layer is game itself. And each of those layers need to use HTTP. The question is whether HTTP handling need to be separately in each of those layers or enough will be one and the other layers will be using it? If I separate the project on to three apk there is many of reasons to use RMI, but I am not sure if this is a proper way to communicate between apk. Let's say that we have gaming application with custom authenticating, rooms with players and vary games. What is the best schema for something like this?
If I separate the project on to three apk there is many of reasons to use RMI, but I am not sure if this is a proper way to communicate between apk
If you think users are going to download three separate apps from the Play Store just to run your game, you are completely off your rocker.
RMI does not exist in Android. For legitimate cases of application integration, there are tons of Android-capable options:
linking activities
communicating via services (commands or binding via AIDL)
broadcast Intents and receivers
ContentProvider
Let's say that we have gaming application with custom authenticating, rooms with players and vary games. What is the best schema for something like this?
Use one APK.
Related
I have two games one is paid and other one is FREE. I have added many themes in my paid app.
I want to incorporate all the new things into my free game and sell things one by one, they both have different package name.
Is there any other way around like sharing user id between two apps rather than copy pasting code base of one to another?
I have developed both games in AndEngine.
You probably want to learn a bit about android Intents. They one way you could share data between the two apps.
http://developer.android.com/training/sharing/send.html
If all you are passing is a simple bit of text it should be easy.
Another approach is using SharedPreferences, discussed in this Stack thread:
The easiest way to pass data between application in Android
Although the poster seems confident, I am not sure that another app can listen to the SharedPreferences of another app. And if you could it could constitute a serious security risk unless there is some way to assure that ONLY your apps can share that data.
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.
So I am developing one application on Android with multiple features. Now I am tasked to replicate this same app in different styles for different customers. When I say style, this may include totally different layout style, graphic, color, language, basically every part of UI maybe different.
However, core function like server connection, data object, payment gateway, etc. Are very similar in every application. The problem is that, all of this application will need to be maintain and develop further. Most of them will be going in the same direction.
What's the best way for me to handle situation like this? I tried to split common methods into Utilities classes for easy plug in the next projects but UI-related stuff like Map and else isn't really easy to separate.
Is there a way to create patch-like function that allow me to unified one core application and slapping different UIs on others? Or something similar.
What you need is a library, you can create an android library project, take a look at this page: http://developer.android.com/guide/developing/projects/index.html
In games like Oblivion there is a thriving 3rd party mod/plugin world. You can get mods for practically every aspect of the game.
How could I write an android game so that I could support additional content written by 3rd parties (which they could charge for in the app store)?
Basically there'd have to be someplace that mods registered their existence and the game would have to check it and then somehow either load data from them (for purely data based add-ons) or execute them (for behavior changing add-ons).
To start with I think I'd mostly be interested in having add-ons which are data (it'd be safest), but I'd like to keep an eye toward executable add-ons.
In a sense you could have all your addons be data addons.
Consider if you wanted to add a new area in Oblivion. You could define a terrain dataset, some static objects as a dataset (trees, rocks, etc), connections as a dataset (doors to houses).
The easiest way is to make your engine just an engine, and the 'game' itself just an addon that you distribute with your engine. Your game is nothing more than a well tested, well thought out dataset.
It gets more difficult when you want to simulate something like a trading card game. Any special mechanics on cards would be limited by what calls you have available in your API. But, depending on how much you open up, the community at large will come up with excellent things!
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.