Guys & Girls, all MTR readers – as you might have noticed, I haven’t been writing for MTR for a while already. So at this point, I would like to announce that I will no longer be able to write new articles for this blog any more.
MTR has been a successful project for me. I exchanged a lot of knowledge, found many friends all over the world and started my own cool Android project with a guy who I met here in this blog.
I am moving to a new exciting position in my company where I will need to keep focused on the higher level picture of IT trends, which includes the mobile world but is not limited to it. I am also highly devoted to my app, Su-Preme MPA, which is supposed to see its first full version released very soon. Thus, to avoid spreading myself too thin, I decided to cease my work on Mind The Robot.
However, this by no means should be the end of MTR itself!
First of all, I will keep the blog hosted and up and will try to answer your comments as often as I can.
Second, if you feel like writing an Android article for MTR, I will be happy to give you an account so you can post it. The blog currently has about 700-800 visits per day so your article will definitely be seen. Just contact me at firstname.lastname@example.org.
Again, thanks for all your feedback, your comments and everything.
Why scan the classpath? There are various patterns that are often used in enterprise Java applications that require scanning of classpath and getting the list of all classes that are present in the application.
For example, if you want to discover all classes with a certain annotation (such as @Component in Spring Framework) to process them in a special way, you need a way to go over all classes in your application and select some of them based on which annotations they have.
However, neither Java SE nor Android have built-in facilities to safely get the list of all classes in your application in runtime. The reason for that is the theory behind classloaders in Java – the ability to go over all classes is neither needed in classic OOP nor feasible for all theoretically possible classloader implementations. However, in practice, scanning classpath and discovering the classes you need is quite possible in most cases, both in your web app and on Android. This is always going to be more or less a hack, but if it has been useful in web applications, it can also be useful in Android apps – with some caution, of course.
Thus, in this article I will show and explain a piece of code that does exactly that – scans your classpath and gives you the ability to go over all classes in your app. Read the rest of this entry »
My definition or, rather, my perception of an enterprise mobile app is generally the following:
The app in question is a mobile client for a multi-user client-server application. It can either be the only kind of client for the app, or co-exist with a web interface or, for example, a PC desktop client for the same server app.
It has a “serious” user interface – rather than trying to impress the end-user with a slick, non-typical UI, it aims to be as straightforward and predictable as possible. It tends to have various forms, charts, trees and lists of various complexity.
Conceptually, very often a big part of the app is dedicated to managing (CRUDing) a set of entities such as users, documents, reports etc. Domain models can get quite complex, often with tree-like structures, fine-grained user permissions with different access levels and profiles.
Internally the app uses typical client-server protocols like SOAP, XML-RPC or even CORBA. Often in-house protocols and frameworks are used on top of those generic ones or instead of them. You get the picture.
Enterprise apps might not seem to be the most interesting kind to work on. However, they are attractive for many studios because customers usually pay well for them. In addition, as a developer, you will find that they are often challenging to implement – at least with functional and internal quality that will satisfy both the customer and you.
In this article, I would like to cover a list of typical facilities that Android developers need when developing such kind of apps. The platform does not really have that much to offer (as we will see), and many developers build their own ad-hoc frameworks that they try to reuse as needs arise.
How do you separate application state, user interaction logic and data presentation in your Android apps?
Platform designers did not enforce any high-level application architecture framework upon us but left us enough options to implement our own solutions based on application requirements and scale. Most simple applications will get away with just storing data in their widgets (such as in text fields, spinners etc.) and their state manipulation right in event handlers such as OnClickListener‘s. However, if you are going to write a complex application or plan to sophisticate your simple app further, you should really think how to layer it well so that the architecture supports adding new features and satisfies the expected performance, flexibility, responsiveness and other requirements, and your code does not become a mess.
In this article, I will show you one practical approach to dividing application code into three layers according the MVC paradigm and connecting the view to the controller using the Android messaging framework. I used it in my own code and although it might not be 100% academically correct or applicable for every possible app, I love the benefits it gives to me as my app grows more and more complex. Read the rest of this entry »
After few months of busy work in the underground laboratories, MTR is back again. As you can see, I have even installed a new theme which looks to me kinda less annoying and more effective in terms of content.
What I plan to do is, of course, to continue the series of articles on Android development so we can go on sharing our knowledge and experience. Many things have been changing in the Android world. Tablets are here today, and new versions of the platform are soon to come. Android is becoming a more and more widespread and seriously taken platform and at this point, there is no way back.
As for this blog, it is still going to be about useful content (at least content that I consider useful), not about promo articles or high traffic volumes. I am still very interested in general architecture topics, plus multimedia (especially audio) and, sure enough, your questions, issues and achievements.
There are many cases where we use byte in our code. In fact, it is the “rawest” type possible in Java unless you go native. Thus, byte arrays are often used to store raw data such as bitmaps, audio and various binary objects.
The previous two articles on MTR were dedicated to audio decoders, including WAV and MP3. In both cases, raw PCM data that was the result of your decoding was a byte array (which you would later write to AudioTrack).
I already mentioned in one of those articles that you should consider streaming any audio that is longer than the reasonable maximum. However, even if your data will definitely fit into the heap, in most cases you can still do better than just using a byte array. Why? Read on (relevant for non-audio bytes as well!) Read the rest of this entry »
In my previous article I outlined the stages you need to go through if you want to manually decode WAVs to PCM to play them on an AudioTrack. I promised to show how to do the same for MP3s and this is what this post is going to be about.
Again, the use case is more common than you might think. The only way you can play an MP3 file via direct Android API is MediaPlayer which is heavyweight, slow and presents only high-level API. If you need to mix or modify audio streams or manage them with low latency, you are on your own. But I will try to help you right now. Read the rest of this entry »
If you’ve managed to hack around the various issues that AudioTrack has, then you are probably enjoying its benefits, such as low latency (in the STATIC mode), ability to generate audio on the fly (in the STREAM mode) and the wonderful ability to access and modify raw sound data before you play it.
However, the problem now is getting that data from a source. Many applications that need to use AudioTrack do not generate PCM audio from scratch (an example of an app that does that would be Ethereal Dialpad and other similar apps). You will probably encounter the need to load and use existing audio samples from file sources such as WAV or MP3 files.
Don’t expect to be able to use MediaPlayer facilities to decode raw audio from WAVs and MP3s. Although MediaPlayer can play those files pretty well, its logic is almost entirely contained in the native layer and there is no option for us to plug in and use the decoders for our own purposes. Thus, we have to decode PCM from audio files manually.