Wikipedia says "Anything between the kernel and the applications is known as middleware". Now, if we look at the android architecture, it consists of:
Applications
Application Framework
Libraries and Runtime
Linux kernel
so, my simple question is what is middleware in case of android architecture? Is it Libraries+Runtime or is it Libraries+Runtime+Application Framework. I read somewhere that it consists of Libraries and Runtime. If that's true then why Application Framework is not considered as a part of middleware, because according to the middleware's definition, Application Framework is also between kernel and user applications.
I'd say it's either:
Application Framework and
Libraries and Runtime
Or:
Libraries and Runtime
I would not say there is only one right opinion, this is a question of interpretation.
I believe its the Libraries and Runtime together.
As middle-ware is the interface between the applications and operating system.
In Android- kernel is operating system and app+app framework is applications.
Then Libraries and Android Runtime together is said to be middle-ware as per my analysis.please correct me if I'm wrong...
In computer science, definitions and later categorization of components to those definitions are sometimes hazy. There is no perfect bucketing of components :-)
Middleware: In practice, these are set of libraries that make it convenient for programmers to access OS or hardware primitives.
In Android, the libraries definitely form middleware. I would not classify the Runtime(read virtual machine) as a middleware.
More specifically, Middleware in Android development, using Redux approach, is a program layer for asynchronous tasks, their managing, scheduling and subscribing. You use it for API requests, logs, analytics, persistence, other time-consuming operations that you want to execute on a separate thread (to free-up the UI Thread, for example).
ReactiveX is a popular Middleware library and approach you can use in your project. Its Android framework is RxAndroid.
Related
I am currently planning the development of a multiplatform app, and I am not sure wich way to do it fits my requirements best, since all possibilties I could think of failed to satisfy me.
First I want to write an app for android, which should feel like a normal typical android app. So I want to use the standard actionbar and android design look and feel in my other gui elements. After finishing the android app I am planning on developing an ios app, which should have a different design, so i am going to redevelop the gui for this anyway.
But I don´t want to rewrite the other code wich represents the intelligence of the app, independent from the gui. I came up with the following possibilities:
1. Java GUI With native library
Here I abstract all the code of my app in a C++ library (since as far as I know ios supports the usage of c++ libraries too) and develop the gui android typically in java. The library would than have a function to start and would inform the gui about every change via callback functions.
Pro
I can reuse all the code that would be the same on both platforms. I just would implement the gui seperately
The design of the android gui is straightforward as I want it to be. It looks like typical android because it is typical android.
Cons
I dislike the usage of JNI very much. Especially the signature and names of the callback functions (calling java functions from c++) are not checked at compile time and require a lot of manual work. If I rename a function and forget to rework the native part I only notice this mistake at runtime.
2. Build the GUI on the native side
Here I had difficulties finding out what is possible, especially for 2.2
2.1 Use Qt
I have only a few first step experiences with Qt in general but as far as I understood i would have the following pros and cons:
Pro
Reuse most parts of the code for ios and Android. I would than redesign the gui for each platform to make them feel natural. I can´t evaluate how much qt may even assists me at doing that
Cons
I have to copy the android gui by using other qt widgets. This is more effort and I don´t know if one can replicate the android gui elements (like the actionbar) so that the user wouldn´t notice it.
2.2 Using the android framework from the native side
I dont know if this is possible at all, I wasn´t able to find this information. Can I use the class "NativeActivity" and use the android framework to build the gui and use e.g. the actionbar? If this is possible somehow it would have the pros from 1. and maybe wouldn´t have it cons?
Do you have any feedback to my ideas or maybe even new approaches I didn´t think of? How do other multiplatform apps like WhatsApp solve this problem? Do they have redundant code for each platform?
Thank you,
Tobi
I would say that it depends very much on your application requirements. By my opinion, a better solution is to develop a separate application for each platform using recommended SDK's for that platform, and implement in native C++ only the time consuming data processing algorithms.
Application runtime on mobile platforms is not so straightforward as on desktop platforms. You should take into account background and foreground processing, specific application life cycling, accessing system resources such as network, file system, etc. And all these issues do differ on iOS and Android.
Regarding possibilities that you listed.
Qt/QML is ok only in case two requirements are met:
1.1 Your application is a foregroud application without any background operations.
1.2 You purchase a commercial Qt license because only commercial Qt can be submitted to Apple iTunes app store (even GPL apps are under
question).
Using NDK Native Activities on Android with cross-platform C/C++ backend. Android NDK API offers much less API then Android Java SDK, so a lot of things you will have to implement or wrap manually. It is a hard road.
Mixing Java code and C/C++ using JNI gives you more of Android SDK API. But you should remember that an Android activity's life cycle is not somewhat that you're used to deal with when developing on C/C++.
Approach that we are using
We've been developing an application with a huge amount of cross platform functionality that should work on Windows/Linux/Mac OSx/Android/iOS. We're using the approach as follows.
Cross-platform core is written in pure C++.
We have adaptors to GUI interface for each platform.
On desktop we use Qt as it reaches all desktop platforms with minor adapting to each platform.
On iOS the GUI is built using iOS SDK with Objective-C and C++ core is linked as a Framework. Still, we had to patch our core in some way for iOS background requirements and so.
On Android we wrap our C++ core in a background process and build all the GUI using only Android Java SDK. Foreground GUI activities interact with the core via local sockets, so we don't need to bother with activities life cycling in our C++ core. But the adaptor is a litle bit complicated.
Nevertheless, both mobile platforms often require workarounds and adaptations in C++ core which add a number of #ifdef'ed branches in code for each platform.
I've been working on a writing a game for Android. Until now I've been using Java instead of the NDK, but I've decided to port my code to C++ (for performance, memory management and industry standards reasons).
Porting my application shouldn't be a problem (I've written my fair share of C++ applications), but I've been using RoboGuice as a dependency injection framework because otherwise my object graph would become too complex rather quickly.
I've been looking around, but I haven't found any resources about using a dependency injection framework in combination with the Android NDK.
Can someone tell me if there any such franeworks available. If so, which one would you recommend?
If you have a C++11 compiler for Android you could use several frameworks (I wrote Infectorpp) but there are others available. You should note that DI is quite limited in C++ due to the lack of reflection so you should make some compromises as not everything you did in RoboGuice would still be possible.
By doing a quick search seems that C++11 is possible on Android. I don't have an Android device and still not needed to emulate it, but if you have any feedback it will be wellcome (private message here or support ticket on google code is enough), the library is headers only so no special build stuff is required for it, apart enabling c++11 on your compiler wich is just one extra option by command line. If that will works good on Android then it will be definitely good also for PC. (Do not misunderstand please, I'm using it heavily, but seems very few people is interested in DI in C++ and so I get very little feedback)
There was also a nice framework cpp-resolver: a little awkard to use because you explicitly register factory functions for injecting ALL parameters, but very scalable, especially for server applications.. (decouple object lifetime management and works with plain old C++).
The most complete framework is probably wallaroo
If you search something really easy to use Infectorpp is a good choice
If you need control over lifetime (mostly servers): Cpp-resolver is perfect
If you need exotic features and configuration files: wallaroo
As side note, run-time configuration is possible also with frameworks that do not explicitly support it:
You just need a Factory that istantiate a different type based on a configuration file you could read through a class that you add as dependency to factories (Probably you don't need to know that since you were already using DI frameworks, but still good to know for occasional readers)
I'm going to implement aodv protocol as a linux module for a research project, and I need to implement it on Android later.I wonder if I could compile my codes into the android kernel and have my module work as in Linux (kernel 2.6 up).
Any suggestions would be greatly appreciated.
(P.S. There are already some aodv implementations on Android, such aodv-on-android and UoB JAdhoc, however, those are implemented in Java, not involving kernels)
The tagline goes: Android is Linux, so anything (portable) you do on Linux should be simple to make happen on Android.
This is mostly true, however there are a few things you'll want to keep in mind:
Portability: If you're writing your implementation on x86 and then moving the module to ARM for Android, be careful not to use any capabilities that don't exist on both. However, for something like a network protocol, you probably won't be running into a lot of these. The only one that comes to mind is the NIC.
Dalvik: Generic Linux distributions tend to run fairly close to the OS, meaning they regularly make system calls or libc calls, and the semantics of interactions with the kernel mostly carry over to the application. Android, however, has essentially a Java environment build on top of that, and the majority of applications only interact with that framework. For you, this means you will want to be aware of the possible need to modify the Android framework in order to make changes visible to applications.
The above point depends on your use case, however. If you plan on augmenting routing for existing applications to use aodv, then you'll want to hack around with Dalvik. If you'll be writing one proof of concept application, then you can write the portions that interact with aodv in C using the NDK, and avoid having to modify the application framework.
You probably already know this, but the kernel built system is sophisticated enough that you should be able to get away with writing your module once and compiling it for two architectures or platforms just by changing your configuration.
Hope this helps.
I've been hired to develop a mobile framework for a webservice created by my employer. Ideally management would like to have some reusable components that can be shared across mobile platforms (initially iOS & Android, probably Windows Phone 7 at some later point).
I've been wondering how feasible this is. One of the requirements is a native interface, so we would use Cocoa Touch on iOS & whatever (Java-based) toolset is used to create a native UI for Android. The application will interact with webservices, mainly the ones that we've been creating internally. The webservices have been developed in .NET.
As far as reusable components go, I guess we could use some C++ code to make webservice calls and perhaps even more of the backend of an application, yet I wonder if this would be a good approach. Apple's Foundation Framework has some excellent capabilities build-in to access webservices, not to mention other open-source libraries, e.g. ASIHttpRequest, SBJSON, etc... I guess the same would be true for Android (though I have no real Android experience for now). Also, when looking at projects done by companies like Google, Twitter & Facebook, each of these companies offers native libraries built for the major mobile OS platforms. If the big companies take this approach, it seems logical for us to follow suit.
Perhaps we should focus more on a general architecture that we should offer across platforms instead of an implementation that can be shared.
Would anyone advise us to make use of C/C++ to develop such a framework (shared library) for the mobile site of our webservices? If so, why?
It really depends on what level of customized code you want to have. I worked at a game company previously, and we made two games for both iPhone and Android, and at least 90% of the codebase was shared between the two platforms in c++ code. Sometimes it is significantly easier to implement elements with specialized third-party libraries, like for Facebook and the like, but maintaining that code means continually doing it for both platforms. That was one of the reasons why we even implemented our own UI objects in c++ for our games. Because even though the initial setup would have been easier to do with Interface Builder and Android's XMLs, the maintenance and tweaking necessary ended up being significantly less because we went with a shared codebase.
In short, I would highly recommend writing any shared customized code in C/C++, and things that are significantly easier in their native codebases (java for android, or obj-c for iphone) and you don't expect to change much, to keep separate.
Depending on which WS protocol you use it may be more or less hard to do, but anyway I see little advantage in doing that in C/C++ for a mobile platform.
If you were using SOAP, I'd never consider C/C++, even for a desktop app. I already used SOAP libraries for C++ and they are a lot harder to use than their Java/.net counterparts, and the way they are implemented (mapping SOAP objects to C structs) is very prone to crashes if the format changes. Not to mention that you have to recompile your client when the WSDL changes.
As I understood in your case you plan to use REST. I never found a good REST library for C/C++, but recently I did a desktop project in which I implemented a C++ REST client using simply WinHTTP (in Windows) and libCURL (in Linux). Of course, they provide just the HTTP part, so I had to add cppdom for XML parsing. If you use JSON, there are many good libs like jsoncpp, libjson.
I'd say to you that even in a desktop environment it was harder to do than would be in .net or java, and was only done this way because it was part of a larger application already written in C/C++.
Anyway, you'll have more work and not much advantage since all those modern mobile platforms provide rich libraries that do the same thing, and probably the user of your API will develop in the platform's main language, so you'll have the double extra work of implementing the WS access code AND the binding code. As I assume all (or at least most) of your logic is in your server, not the client, there's not much common code between the platforms to justify using C/C++.
Not really an immediate source code question per se....but Im looking into doing some casual Android Programming, nothing heavy.
But it seems to use alot of XML and Java......what I wonder though is why is it that android is written mostly in C and XML (along with C++ and Java) with it being closely related to the Linux OS......but why is the "main" language for programming in android Java?
Just out of curiosity of course.
The "main" language, as you called it, is Java. You can use C/C++ via the NDK, but you won't need it unless you are doing some special stuff. If you wonder when you would need to use C/C++, take a look at the official documentation:
When to Develop in Native Code
The NDK will not benefit most applications. As a developer, you need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but always increases application complexity. In general, you should only use native code if it is essential to your application, not just because you prefer to program in C/C++.
Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. Simply re-coding a method to run in C usually does not result in a large performance increase. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need. The NDK can, however, can be an effective way to reuse a large corpus of existing C/C++ code.
The Android framework provides two ways to use native code:
Write your application using the Android framework and use JNI to access the APIs provided by the Android NDK. This technique allows you to take advantage of the convenience of the Android framework, but still allows you to write native code when necessary. You can install applications that use native code through the JNI on devices that run Android 1.5 or later.
Write a native activity, which allows you to implement the lifecycle callbacks in native code. The Android SDK provides the NativeActivity class, which is a convenience class that notifies your native code of any activity lifecycle callbacks (onCreate(), onPause(), onResume(), etc). You can implement the callbacks in your native code to handle these events when they occur. Applications that use native activities must be run on Android 2.3 (API Level 9) or
You cannot access features such as Services and Content Providers natively, so if you want to use them or any other framework API, you can still write JNI code to do so.
I am just guessing but Java is a bit easier to program than C/C++ so its more attractive to new programmer which is also good for the platform success itself.
Another reason might be that an application written in java runs in a separate VM so it can be much easier controlled by android. If a vm is not responding the main OS can just kill it and the phone is still responding.
Suaron... From a stability point of view Java apps should be less likely to take down the device. So Java || C# || C++/CLI safer than C++ vs C vs Assembly. To this end the API is in Java and so most Apps are in Java.
On the other hand C/C++ gets closer to the hardware and is more appropriate for writing libraries that interact with hardware. It is much easier to shoot yourself in the foot with C++.
JAL