We Keep Coding

Android Apps using python

I found that Android development can be done through Python from the link http://www.linuxplanet.com/linuxplanet/tutorials/7157/1. My question is whether all the libraries that are available in Java are also available in python.
Any of you already started with python on Android if so please indicate links to help get our group up to speed.

No, not all the libraries have been exposed. You can look at the SL4A project on google-code for more information regarding the support it has.
Is this a complete API bridge, or are there restrictions?
BeanShell, JRuby, and Rhino basically give you a complete API bridge (you can invoke Java calls directly). See the documentation for those interpreters for instruction on how to accomplish this. Cross compiled languages like Lua are more restricted. They only have access to the APIs exposed through the RPC layer. See the API reference for a list of currently supported APIs. The RPC layer is easy to extend.

USB software protection dongle for Java with an SDK which is cross-platform "for real". Does it exist?

What I'd like to ask is if anybody knows about an hardware USB-dongle for software protection which offers a very complete out-of-the-box API support for cross-platform Java deployments.
Its SDK should provide a jar (only one, not one different library per OS & bitness) ready to be added to one's project as a library.
The jar should contain all the native stuff for the various OSes and bitnesses
From the application's point of view, one should continue to write (api calls) once and run everywhere, without having to care where the end-user will run the software
The provided jar should itself deal with loading the appropriate native library
Does such a thing exist?
With what I've tried so far, you have different APIs and compiled libraries for win32, linux32, win64, linux64, etc (or you even have to compile stuff yourself on the target machine), but hey, we're doing Java here, we don't know (and don't care) where the program will run!
And we can't expect the end-user to be a software engineer, tweak (and break!) its linux server, link libraries, mess with gcc, litter the filesystem, etc...
In general, Java support (in a transparent cross-platform fashion) is quite bad with the dongle SDKs I've evaluated so far (e.g. KeyLok and SecuTech's UniKey).
I even purchased (no free evaluation kit available) SecureMetric SDKs&dongles (they should've been "soooo" straighforward to integrate -- according to marketing material :\ ) and they were the worst ever: SecureDongle X has no 64bit support and SecureDongle SD is not cross-platform at all.
So, has anyone out there been through this and found the ultimate Java security usb dongle for cross-platform deployments?
Note: software is low-volume, high-value; application is off-line (intranet with no internet access), so no online-activation alternatives and the like.
-- EDIT
Tried out HASP dongles (used to be called "Aladdin"), and added them to the no-no list: here, too, there is no out-of-the-box (out-of-the-jar) support: e.g. end-linux-user has to manually put the .so library (the specific file for the appropriate bitness) in the right place on his filesystem, and export an env. variable accordingly.

Full disclaimer: I work for a company that makes software-protection dongles (CodeMeter). But I believe we might have a solution that meets your requirement: we have a single API for all platforms (Win, Mac, Linux, etc both 32- and 64-bits). Each end-user machine merely requires a runtime (service on Windows; daemon on Linux). We use a native Java API which uses TCP/IP to call our runtime, so no special device drivers are required. You can do activations either before you ship the dongle (pre-programming), or via file exchange (NikeNet) on deployments with no Internet access, or you can remove the dongle, take it to a machine that DOES have Internet connectivity and update the license there.
At a higher level than the API we have AxProtector, which is an automated protection/encryption tool that you can use to test our protection system with no source code changes. This would let you test the implementation on all platforms you are interested in--you don't need to create multiple versions for different platforms.
We had a Fortune 100 company use this to protect a Java app that ran on non-Intel Solaris, so we know it's been stress-tested as a cross-platform solution.
We have a free fully-functional eval system which we can get you asap. If you email me at the email address in my profile we can ship you out an SDK and help you quickly determine if this will solve your problem.

You can use Dinkey Pro dongles to achieve exactly this. While they do use separate native libraries for each operating system and architecture you just need to call their Java API and it takes care of any platform specific bits. Wrap the libraries up in a JAR file with the .class (the API) and you've got a neat solution. The dongles themselves are driverless.

I can only recommend to avoid the SecuTech UniKey system. During evaluation the product met all requirements we needed. We started integrating this solution and discovered one issue after another.
Here is a short list of the major issues that are part of the SDK 6.2.7:
Enveloper settings change randomly when saving and loading the same solution (Video).
DLL files that are wrapped with the enveloper do not load.
The console version of the enveloper for script based builds does not work. It is unable to wrap exe/dll's that can be wrapped with the GUI based version of the enveloper.
Support is reactive but does not really tackle the problems.
After all we wasted almost a month of work integrating this protection system, but now have to switch due to the massive quality issues.

Scala or Java based on IDE and Memory footprint

We have huge stack of xml files (around 5000+ files) possibly about 80 MB when not compressed) all of them are device configurations used for read & write data & build user interfaces without any language dependencies. These XML files can be ported to any technologies like Android and Apple world. Not all the 5000+ are loaded at one shot to memory, we might load 200 files into memory based on 1 device connected. We have a .NET/WPF based application which is using those XML files to build the UI and access the device information through protocols like Modbus & Hart (Don't bother protocols now). Anywhere we need custom logic, we have written them in DLL's (in .NET) and we use the reflection & IoC to load those DLLs, create object and access them through interfaces at runtime to complete the XML configuration. On desktop, then we build UI and load configuration
Now We need to develop Android app which runs on Phone and tablet as well. I have 1 year experience working lightly in Java. We could write a core modules which can be used for both phone and tablet and UI layer which is just to render our XML as a UI elements. We know to use Java's Class Loader to create instance so that instead of DLL's we could build .jar file in Android world and load them (if possible?) and access via interfaces. When we load our XML, it will consume nearly 80 to 100 MB of RAM (in WPF & .NET).
When looking into Android world, I could not decide whether to go with Scala or Java. We do not have any Java expert to advise us. Having worked on Python, I feel like Scala is modern & good choice. Also I read that Android apps compiled using Scala is fat(big), take long time to boot up.
But coming from Visual Studio background, we are much sophisticated development team expect everything to run through IDE. Also team has to learn Java/Scala whatever our choice from start.
If we choose to work on Scala on Android, do we except the memory efficiency is near to Java? Also do we have sufficient IDE support (Eclipse or NetBeans or IdeaJ) for Scala?
I am specifically looking for Memory footprint (internals) and IDE support for building Android application. No discussion on performance or productivity..

My Scala IDE is Maven in one terminal window and Vim in another. The browser serves up help documentation. If you can base your build process on Maven, then any IDE should do fine. And since you are working a lot with XML files, I suggest that you do base your build process on Maven rather than SBT.
Of course, there is Eclipse support for Scala, Intellij supports it, there is a Netbeans plugin for Scala, even a Komodo language extension for Scala. Lots of IDE choices to try out. Only the developer knows what works for them.
Make half a dozen identical VMs. Install one IDE on each one of them. Get the developers (end users of the IDE) to test them and choose the one that they want. Do all of the build and continuous integration with SVN and Maven. Make that the boundary between the developers'personal toolset (the IDE or Emacs or Vim) and the supported development tools.

If you're coming from C#, I'd advice choosing Scala. That way you could actually preserve some of your business logic, because good C# code might probably look a bit like things are done in Scala, too. E. g. LINQ in C# and Scala's collection classes (v.s Java collections).
The syntax is a bit different compared to Java/C#, but syntax is hardly a real problem these days.
Java's IDE support is pretty good, but if you're coming from Visual Studio, Intellij (or Eclipse) + Scala plugin might be good enough for you.
If you program the same code in Java and Scala, memory consumption should be pretty the same.
You should keep in mind that you should use ProGuard to keep the size of the Android application manageable.

How to create a mobile oriented, multiplatform, shared library in Java?

I have a Java application that runs on BlackBerry (JDE 4.5). I want to port this application to Android, and be able to maintain the 2 applications simultaneously. I may also want to port this application to other Java platforms (J2ME ?).
I understand that a good part of the code will have to be specific to each platform (UI and other stuff). But I also feel that a lot of the code could (should) be shared (domain related classes).
What is the best way to achieve this, and what are the pitfalls to avoid?
I have been able so far to create a JAR with all my shared classes, that I have been able to integrate into my BlackBerry application (using preverify and rapc). But:
The JAR is a J2SE library. How can I make sure that it will run (or even compile) on BlackBerry, Android or J2ME?
I am also using a JSON library targeting J2ME (https://github.com/upictec/org.json.me/). This library seems to make use of some kind of preprocessing directives (CLDC, see https://github.com/upictec/org.json.me/blob/master/src/main/java/org/json/me/JSONObject.java#L392). How can I use (or convert) this library using the right preprocessing definitions?

This is likely to be difficult:
As you have already identified, the UI code will have to be different for each platform.
There are major differences between Java SE / Android and Java ME-based platforms. For example, ME doesn't have the Collections framework, or the java.io or java.nio stacks.
It is hard to predict from the information you've provided, but there's a fair chance that you'll spend more time fighting the platform dependencies than you are saving by sharing the code-base.

These days, the biggest stumbling block to sharing code this way is that the BlackBerry VM and Android VM both support different versions of the Java language. BlackBerry uses a subset of Java 1.3, Android uses a subset of Java 1.5. (As an aside, neither platform implements a Java VM, both use their own VMs. Java is used as the programming language. Java bytecodes must be transformed to the appropriate native VM format before they can run on the platform.)
The biggest difference you will find as a library implementor is that the BlackBerry lacks the things that were introduced in 1.5, very important things like generics and enums. Even worse, the Collections classes are missing from the BlackBerry. It is unfortunate, but that is the way it has been for a long time now.
This means that to be truly portable you have to write to the lowest-common denominator, which means using (very) old-style classes like Hashtable and Vector, not having generics, rolling your own enums (as in the 1st edition of Effective Java) and so on.
Or you build two libraries, a modern version for Android and a stripped-down version (with just the bare stuff you need) for the BlackBerry.
Hard to say what`s right for you.

Rather than prepackage your shared library, I would consider sharing the library project and having it as a dependency in your mobile applications' build process. That would allow you to share the code base, but have it built by the appropriate builders for your target devices. With a bit of IDE magic and some attention to detail, you should be able to pick up errors before anything is shipped out.
Alternatively, set up your library project to use two separate builders to pick up errors. That would allow cleaner distribution, but you may run into problems trying to convince your IDE to treat the project as being device specific in order to identify problem areas.
It would be likely that you would end up supporting the lowest common denominator device (cough Blackberry), and forgoing the additional facilities of the more extensive Java implementation on Android.
Unfortunately the answer will be one of experimentation. Try it and see what happens.

The article Porting Android code to BlackBerry has some good detail on how to work with code shared between the two platforms.

it will be very difficult to create shared library for blackberry and android.
if you want simple method, create your application as web app.
using
phonegap with jQtouch

What is the difference between API & Framework [duplicate]

Now, this may be a silly question but sometimes the terms Framework and API are used interchangeably. The way I see it is that a Framework is a bigger more generic thing, containing many API's, that could be used for various programming tasks (for example, the .NET Framework.) An API is smaller and more specialized (for example, the Facebook API.) Anyone want to share their insights on the matter?
And take for instance that Microsoft call .NET a Framework whereas Sun calls theirs a Platform ... so could it be also a business/marketing decision as to how call a "collection of libraries."?

Design Patterns provide the following definitions:
toolkits: "often an application will incorporate classes from one or more libraries of predefined classes called toolkits. A toolkit is a set of related and reusable classes designed to provide useful, general-purpose functionality".
frameworks: "a framework is a set of cooperating classes that make up a reusable design for a specific class of software".
The key here is that while toolkits (APIs) can be useful in many domains, frameworks are geared to solve issues for specific classes of problems, that can be customized "by creating application specific subclasses of abstract classes of the framework".
Moreover, and maybe more importantly, "the framework dictates the architecture of your application": Inversion Of Control is one of the characteristics of frameworks (see Martin Fowler on this); instead of having your application call specific APIs to implement a specific behavior, it's the framework that calls your code.

I've always thought the framework was the whole thing, internal code, API's, etc.
While the API is just the bit you use when you want to make use of the framework.
In other words, the .NET framework consists of the .NET libraries, all the languages and so on. The API is just the way you call the functions.

A framework does introduce the notion of inversion of control
(i.e. the overall program's flow of control is not dictated by the caller, but by the framework)
When you are referring to language frameworks (such as Java Framework or .Net Framework), you actually including more than just libraries and their APIs (which would be more limited a Software Framework if those libraries provide an inversion of control).
A Language Framework includes the development and execution environments which will call your code (to compile it or to execute it).
That is why .Net Framework is a "Framework".
Java may refer to its Frameworks (JDK, JRE) as a "Java Platform" in order to emphasize its "platform independent" programming language feature.
From About the Java Technology
A platform is the hardware or software environment in which a program runs. (including Microsoft Windows, Linux, Solaris OS, and Mac OS).
Most platforms can be described as a combination of the operating system and underlying hardware.
The Java platform differs from most other platforms in that it's a software-only platform that runs on top of other hardware-based platforms.
The Java platform has two components:
The Java Virtual Machine
The Java Application Programming Interface (API)

As its name suggests (Application Programming Interface) the API is just the interface of the framework.

From my understanding, an API is basically a way of interfacing with an existing app (like Facebook), whereas a framework is basically a tool for building your own app from the ground up.

Software Framework: Is a re-usable design for a software system (or subsystem). A software framework may include programs, code libraries, a scripting language, other software to help develop and glue together the different components of a software project. Various parts of the framework maybe exposed through an API.
API (Application Programming Interface): Is a set of routines( AKA methods, functions), data structures, object classes, and/or protocols provided by libraries and/or operating system services in order to support the building of applications.
More details along with other
Link to this particular topic is
http://aprogrammersday.blogspot.com/2009/02/difference-between-framework-and-api.html

API (application programming interface): like his name means, is an interface for externe programs to interact with your inter program or library without having direct access. for example, the google map API and Facebook API give you the interface to interact with their program and library without having direct access.
In the other hand:
Framework : is a collection of libraries that can help you to build an application. you can imagine the framework as a "skeleton" where the application defines the "meat", so you can't take a human skeleton to build a hors body, so you have to choose the good framework before start programing. this is why we said : You call Library. Framework calls you.

I'd like to think that an API is a subset of a framework

In my experience, a framework often includes two things (at least) that an simple API doesn't:
Extensibility: you can compose or subclass framework components to extend or customize its functionality.
Tools for code-generation, administration, or diagnostic tasks related to application development.

A framework is basically a collection of classes that abstract away the development process and promote code reuse for example you might have database, session, and pagination classes that are independent of the application you are building. But an API is source code interface that allows two or more components of different systems to interact, for example adding the Google Maps API to your website, you and Google are two different systems, Google coded the underlying interface for incorporating its products to your website/application. All in all just go with a framework work when building your system, then develop an API when you offer extensions for other people like Facebook and Google.

I know this is an old thread and that it really doesn't matter, but I just can't help but to chime in with my own views. An API (e.g. device driver API, Windows API, etc.) provides the basic and essential functions for a platform such that a programmer can exercise his creativity and do something with the platform - yes, including using it to build a framework. A framework is higher level in function and abstraction, and provide a set of reusable and convenient functions/classes/conventions to facilitate the development of applications that share certain common attributes (e.g. iPad apps, web services, etc.)

A framework implements a very important option called IoC (Inversion of Control) which means in a nutshell that your code has, no more, things in hand.
While in an API your code calls other codes (libraries), when you use a specific framework, it's the framework who is in control of the application flows.