I'm considering creating a screen reader for Android. My questions are as follows. One how much of the internals of Android are exposed through the Java API? I'm looking for things such as system wide notification when text is displayed, notification of a new application being launched, etc. I'd rather not have to modify the kernel source and only allow my app to run on a developer phone. Two, how much processor and memory are left over on the G1 assuming no applications running? Three assuming average use of applications on the phone how much processor and memory are left?
More info
I'm aware that applications should not be designed to work on a specific phone. I picked the G1 because it's the most popular phone currently running Android that I know of. I am looking for lower end system specs that my program would have to fit in, it may run great on a netbook with Android installed but use to much memory and processor to run on most Android handsets.
Update:
There are now two screen reader projects that use Android 1.6, they can be found at
http://google-opensource.blogspot.com/2009/10/talkback-open-source-screenreader-for.html
http://spiel.thewordnerd.info/
AFAIK, screen content (text, graphics) of other apps will for security reasons not be exposed in Android. Otherwise one could grab contact info or whatever personal information gets displayed and harvest that for malicious purposes. So developers currently cannot create an Android app that speaks the text displayed by another application, nor capture the screen. This situation is different from Microsoft Windows on the PC, where applications can do pretty much anything they like, such that the user must decide for himself whether the source of any given application is trusted.
Sadly, there is still no screen reader for Android on the market, so it would be great if you or someone else could create it, but it looks like only a direct arrangement with Google could provide the level of trust needed in view of the above security limitations. Since Google is actively working on improving the TTS and integrating it into Donut, it would seem a fairly simple extra step for them to create a basic Narrator-like (as in Windows) screen reader, or offer a similar touch-based accessibility solution as with VoiceOver on the iPhone 3G S.
Best regards,
Peter Meijer
The vOICe for Android
http://www.seeingwithsound.com/android.htm
(1) Depends on what you are looking for. You better check for yourself. I am not ware of any assistive technologies in place, but I wasn't looking for them either.
Regarding the two specific capabilities you asked for:
(a) Notifications are part of the API.
(b) I am not aware that you can be notified on applications being started.
(2/3) I don't the general amount of RAM that is available for apps, but I can give you an practical answer. Your app's process will be killed if it tries to grab more than 16MB.
I don't know the exact clock speed, but on the android-dev list it was mentioned that the G1 doesn't run at full speed. The rationale behind it is that among other things more speed would run down the battery much more quickly.
Just another practical matter regarding this question. If you want to discuss the constraints go to the android-dev list.
Related
So I'm looking to make my own not so smart "smart" watch Bluetooth device. From what I've found online, I will need some sort of "brain", a thing capable of using BLE, and since I want a display, also an led screen. I need to display the time, and be notified when a call or text is received.
My question comes down to these 3 points-
What should I use/buy for the brain? I'm assuming some sort or variant of a little cpu? I'm also going to need the Bluetooth side of it, but I'm unsure of what I would need that is capable of giving BLE to my device.
Is it possible to make the software side out of this in Java? It is the only language I know extensively, but I'm willing to learn any of it is needed.
Is there anything special I would have to do to pair it with an IPhone (such as make an app, code it a certain way, etc)
I'm sorry if at any point I'm too vague (I don't know enough not to be) or if I'm oblivious to any well known facts; this is my first time ever building an electronic device.
If you would like a smaller cheaper solution and you're somewhat accustomed to working with micro-controllers, I would say look at something like Arduino Micro plus a BLE shield or another brand micro-controller.
Arduino uses its own functional language that's fairly easy to learn coming from java and any other micro-controller would probably use C, if you decide to go that route. A micro-controller would most likely not support java, because the JVM is simply too large and has too much overhead for a tiny cpu.
The time should not be an issue to update via BLE. You can implement the calling and SMS via the ANCS protocol.
Here is a good example/tutorial for an arduino "smartwatch".
I'm writing an application to collect information about a users behavior in front of the computer in order to study usage patterns. I've looked into JNA but can't find any information about how to capture the active application for platforms other than Windows.
Are there any libraries (such as JNativeHook) to capture the active application in OSX?
I would like to capture the active application rather than the active window title in order to avoid integrity concerns for the user study. Also, I know that Java is not really meant to work outside the JVM and capture this sort of things, but since there are a lot of database interaction and a limited amount of time Java was chosen and the project is completed except for this component.
Sure, for a "user study" ;) ;)
In Objective-C, you would do something like:
NSWorkspace.sharedWorkspace().activeApplication()['NSApplicationName']
I may be off on the exact code, as I don't have access to a Mac right now, and doing that from memory/APIs, but I think that is close. The important starting point is NSWorkspace. Now, how you go about calling that using JNA, I haven't the foggiest.
I'm developing an application for Android, and I'm thinking that it's functionality might be useful on other (Java-running) platforms (say a regular desktop app -- although I hope that the other platform(s) involved are immaterial to the question at hand).
It's unlikely that the UI will be in any way portable (there's just too much of a difference between a good touch-capable, 4in screen UI, and a mouse-and-keyboard 19in screen UI), so I'm happy enough reimplementing that separately.
However, the core "business logic" (ugh, horrid word) and model (data storage) classes could, in theory, be reused in managing the core app. I've noticed that there aren't a lot of classes I'm writing that don't end up referencing some Android-specific bits (I've got XML resources files, images, and SQLite databases, as examples). Basically everything I've written so far has at least one Android-related import.
My question is twofold:
What tools are available out there to help me use Android-related classes and features (eg resources, databases) on non-Android platforms; and
What classes, features, etc of the Android platform should I completely avoid using (for the sake of simplicity, let's exclude UI-related items) due to non-portability, and what should I use instead to improve portability.
Answers that consist of "hahahaha, you're doomed" are OK, as long as there's some rationale provided.
(P.S. I'd make this community wiki if that was still available; this seems like a perfect CW question to me -- a list of Android portability tips and tools)
Looks like you have already identified the key point by keeping UI and biz logic / model separate.
Also sqlite itself is used not only in Android. But of course the way you interact with it (e.g. SQLDBOpenHelper) is different again.
So I guess having the biz logic and model as separate as possible is the way to go.
You can then put a wrapper around it (e.g. "Data Access Object " pattern which talks to the specific DB).
Still keep in mind that the users experience is best when you are as specific to a platform as possible on the UI side.
Example: there is an App (Push & Ride) on the Android market, which seems to run in a J2ME emulator. So screen input does not use the normal soft (or hard) keyboard of the device, but a simulated phone keyboard with the "abc" "def" combos on the number keys, which makes data entry a bit strange.
This app is for sure very portable (and its functionality is really great), but it just does not feel right.
When you want to go multi-platform, you may perhaps also look at things like Appcelerator or Adobe AIR
I started off doing something similar - I wanted to write an app for Android, Blackberry and J2ME. Conceptually, you can layer your design such that platform-specific components (UI, network access, data storage) are separated from the core business logic.
In practice, I don't find this satisfactory. The issues I faced all related to the core version of Java being different in the different platforms (in Blackberry it is based on J2Se 1.4, while Android used Java 6 as base). This led to annoyances like
Not able to reuse code that uses generics
My preferred classes not being available uniformly (for example, forced to use Vector over List)
I have opened discussions regarding this on SO (here and here), but couldn't reach a conclusion.
The logging layer can be made portable by using the Simple Logging Facade for Java(SLF4J) which is available for java/log4j and for android.
Also,you can try this out
http://wp7mapping.interoperabilitybridges.com/Home/Library?source=Android
Contains documentation and tools to map your android app to windows phone
Also read this,even though it contains instructions specific to android - windows phone interop,im sure they apply to other platforms as well
http://windowsphone.interoperabilitybridges.com/media/49652/wp7_guide_for_android_application_developers.pdf
What I do is create a web service outside of the android app which can be used by the android app as well as other systems (websites, windows apps, iphone apps etc).
A simple REST web service which supports JSON is a good example to fetch data and also insert/update data. JSON is particularly suitable because its so lightweight, and doesn't require alot of bandwidth which is great for slow mobile connections.
This way you can store your models/data storage outside of the android app, and it can be used by other apps very easily.
The database layer can be made more portable by using android jdbc or by using a database abstraction layer/object relational mapper/ActiveRecord implementation.
Has anyone tried make android.database(.sqlite) runnable on a non android system?
If you carefully separate business logic from UI and android perks you would be able to reuse it in desktop environment. Android is quite different from it in intialisation and application lifecycle - abstracting creation and setup of BL is also necessary.
Usefull pattern for this purpose would be dependency injection. There are different frameworks around, and some are more suited for android (like roboguice) or desktop (spring or picocontainer or guice).
Android appliactions are very constrained in memory, and this puts limits on what frameworks you can use there. So you may need to abstract data storage as well ( hibernate comes handy on desktop / server side , but too heavy for mobile device)
I'm inclined to suggest trying out the new native extensions for Adobe Air. It allows you to create a device-specific chunk of native code, and connect it to the Air framework, accessing it as you would other objects in Air. (cf. http://www.adobe.com/devnet/air/articles/extending-air.html). This allows you to keep the Android-only code as is, and then replace that code with iOS, Windows DLL, etc. code as needed.
This doesn't solve the problem of translating Java code to other languages/platforms, of course. Still, some of the logic you are doing natively may very well exist already cross-platform in Air. For example, you can access the camera in Air in all supported OSes without writing any device-specific code.
You will probably need to go beyond the current Air classes, so some examples may help:
Android speech-recognition
iOS batttery
Windows and Mac tutorial
NE tutorial
I am currently trying to implement a database compatibility layer for Spring-Boot-JPA/Android-Room:
"compatibility layer" means my Service-layer-code is pure-non-android-code that can be used in android and in spring-boot. The Service-layer-code uses a common java-repository-interface that is either implemented in android-room or in JPA.
Currently i am stuck here:
Howto use methods of CrudRepository<T, ID> (or SimpleJpaRepository<T, ID>) in a Spring-Data-Repository-Fragment method?
I plan to go with the free version in order to promote the paid version.
Few questions:
In your experience, is it helps?
After a user has installed the free version, if he wants to install the paid version,
he needs to remove the free version first ?
how it effects downloads rates ?
What is the correct way to do it?
After some research for one of my applications, I have found the following options:
1 - Have all your code in one big library then make two applications using this shared library and have them toggle some flag saying the application is in trial or full mode.
To me, not very nice, because you'll need to handle the fact that the user can have both the free and full applications installed, when the users gets the full application, you'll need to move his data from the trial version to the full version (databases cannot be shared easily)
2 - Have one single application that can be unlocked by buying a code on a particular website
Good thing is you can provide alternate payment options (paypal, ...) and also avoid being limited to the Android Market. Can be nice when dealing with countries that don't have access to it.
3 - Have a single application with all the code plus one small unlock application to unlock the free application limitations
Good thing is you just need to update the free application and all users will get bug corrections. You also take advantage of the Android Market. Downside, is that your users need access to the market to get the full application.
I have personally chosen option 3 but I will add on top of it the option 2 because I intend to distribute my application on countries/devices that do not have access to Android Market
Edit 2/2/2011: I have published an article about that on our website. Your can read it there: http://www.marvinlabs.com/2011/01/sharing-code-full-lite-versions-application/
It's always a good idea to provide a demo (assuming there is incentive to buy the paid version, like a time trial, feature cripple, whatever is best to demonstrate the app without ruining the experience).
Add two versions of your app to the market, one free, one paid.
No, since they're two separate apps, but it would make sense to remove the free one in order to not have two apps installed.
They're two separate apps, so they have two separate counts.
As an alternative, you could use a keyfile to unlock the features of the full version. If you do that, you should probably use Google Checkout for processing (all "fees" must go through Google's processing as per the TOS, IIRC). There's a lot more involved if you go this route (especially coming up with a keyfile system that cannot be easily hacked).
Hai friends,
I have a doubt now,
Has Android really replaced J2ME and
WML?
If Android has replaced these, then
please tell me, what is the reason for
that?
How Android has replaced the other two
mentioned above and
what is the
reason that J2ME and WML cannot
withstand against Android in market?
J2ME is a java platform for embedded devices. Android is a mobile operating system. So you can't make a direct comparison.
However, if you look at the Java based Android SDK vs J2ME: The share the same basis with the core Java libraries. They provide different UI layers and application paradigms.
Android is more powerful, and thus used in higher end phones. However J2ME is still used in a lot of older/less powerful devices. The Androd SDK provides a lot of things that are not part of J2ME. You might want to read through the dev guide to get an idea of what Android is capable of.
Android phones are getting cheaper, soon you could get an android phone for almost the price of the mid-range J2ME handsets
Android SDK doesnt face the issue of the first mover that J2ME had, so the SDK is quite powerful and in tune with the times, where as J2ME wasn't updated for years
Android, though fragmented in terms of versions, doesnt have the JSR nightmares that J2ME has (Vendors not implementing the JSR completely or in a different fashion)
However, things could really be great for J2ME, if Oracle succeeds in making the J2ME.next, We could really get an almost write once run anywhere, if they can somehow also allow installable VM's like standard J2SE VM
I would argue that Android hasn't completely replaced the two others, they obviously still exist and there are other platforms that still use J2ME. But, even so, I think it has practically replaced the other two just by virtue of its popularity.
The market share for so-called smart phones is growing rapidly, the market share for Android phones is growing rapidly. I don't see the market share of any devices based on J2ME growing rapidly. As for WML, I don't see it growing either because most smart phones now feature a browser that is far more capable than mobile browsers of the past. The one I have in my iPod Touch is very good, the one on my Android phone is adequate for most sites. I don't have to have special sites built just for my phone any more. It's nice if they are there, but they definitely don't need to be constructed using a different markup language, a simple alternate CSS style sheet would probably do just as good a job.
There are some considerations that are helpful that sites can take into account with regard to width and use of Flash, etc. but I would argue that the need for WML has gone away for the most part before it ever became really popular.