Question: When can I say cross platform tools can handle this type of development..?
Below are NOT questions to answer. These are just guides why I raise the question to avoid too long description.
For game development :
Are tools (i.e phoneGap, widgetPad etc...) alike (given these terms...openGL, xna, 2d, 3d and others..) sufficient enough for game development?
For Applications development :
Like in native android, can the cross platform tools would still be able to do the same as native java does? i.e. Accessing notifications, contacts etc..
I would say at the current time, it is not ready for 1 and will really not be anytime soon (without undo trouble to the developer that in the end is a setback).
As for 2, it can and is ready for your question immediately. Sure, you have to still call the native Java or Obj-C for some truly native features, but this can all be done from within the Javascript/HTML interacting into the Java domain. This, they call plugins, and albeit a nightmare to upgrade at some times(pre 1.9.0, but anything developed after 2.0.0 won't have those issues to deal with (mostly))
Check out ADF Mobile just released on Monday (Oct 22, 2012) for business software. It provides Android and iOS solution and it is Java based. The info can be found here:
http://www.oracle.com/technetwork/developer-tools/adf/overview/adf-mobile-096323.html
With the platform and device diversity reining the mobile landscape, cross-platform app development has emerged as a commercially viable option. Here are the the Top 10 Cross Platform Mobile App Development Tools
https://www.rootinfosol.com/top-10-cross-platform-mobile-app-development-tools
Related
We have developed a Windows based Desktop application using Java Swing and build a exe of it using javapackager available in Java 8.
Now we are trying to automate the testing of it using Karate-Robot but Robot could not detect the fields on the GUI of Application. To further dig we have installed AccessibilityInsights suggested by Karate Community to figure out how to access elements on the GUI but it seems that our application is not getting detcetd in it. See attached screenshot.
Can someone help us on how to fix the application?
Will Java Accessibility Bridge help here? As per documentation https://docs.oracle.com/en/java/javase/11/access/java-accessibility-guide.pdf, Application needs to implement Java Accessibility APIs when it needs to be available to Windows Assistive technologies.
Edit 1: As per https://docs.oracle.com/javase/tutorial/uiswing/misc/access.html, "Because support for the Accessibility API is built into the Swing components, your Swing program will probably work just fine with assistive technologies, even if you do nothing special."
Ashish--
There have been multiple iterations of Windows-based assistive technologies over the years. The current iteration has existed since 2005 and is called UI Automation. This is the technology that is required for OS-provided tools like Magnifier and Narrator. It's also the technology that is required by Accessibility Insights for Windows. From your description, it might also be the technology that is required by Karate-Robot.
Java Accessibility Bridge uses an older iteration of assistive technology that is no longer recognized by OS-provided accessibility tools. It is recognized by some third-party accessibility tools (JAWS and NVDA, for example), but it is not recognized by OS-provided accessibility tools. To the best of my knowledge, Oracle has no plans to support UI Automation in the future. When their docs say that your apps will "work just fine", they're referring to users who rely on these third-party tools.
Accessibility Insights for Windows has made a conscious decision to support only UI Automation, since supporting 2 platforms would make things much more difficult. We chose to go with UI Automation because it is the only technology that is:
Actively supported by the operating system, with new features being regularly added and documented.
Supported by native Windows controls and most actively supported language frameworks.
The technology that we would expect new assistive technology tools to implement first.
I'm sorry to be the bearer of bad news on this.
DaveTryon (Accessibility Insights team)
I am using Ubuntu on my computer, and I do not want to switch to another operating system.
I'm looking for a software that would let me program cross platform apps (for smartphones) with one programming language.
I would prefer a .NET language. Yes, I have looked at Mono, but they only offer their software in Windows and Mac.
Is there a software that would let me build a cross platform app? (I don't like Java, but JavaScript is one that I can handle)
MONO is available for more than both Mac and Windows. It runs in Ubuntu and instructions can be obtained from here.
iOS apps can unfortunately not be built without xcode, but the coding can easily be reused between Ubuntu and Mac. One software to checkout is Xamarin which allows you to use c# to develop iPhone and Android apps. I've been coding in .Net for a while, and I have to say that when I had to do a unix class project, MONO and Xamarin saved my life
Note: I know that your question specifically said you don't like the idea of switching platforms like you would need to in MONO, but I've done a lot of research on this and I've determined it to be my best option, I'd think it'll work for you if you're willing to use a Mac or PC
I'm looking for a software that would let me program cross platform apps (for smartphones) with one programming language.
If you are looking for some tools for developing cross platform apps for smartphones, I suggest you PhoneGap
Is there a software that would let me build a cross platform app? (I don't like Java, but JavaScript is one that I can handle)
You are using ubuntu and want to use .Net, No this is not a convenient solution. If you want a platform independent language, I absolutely suggest you, JAVA ;)
Please notice that:
Java IS NOT JavaScript and they are not related to each other.
I had the same question. I did come across Appcelerator. It seems that they supported Linux previously and the single language you can write in is Javascript.
It's not opensource. You have to make an account to download and install it, but there's free versions for solo developers. I'd rather use Kivy to develop in Python though ;)
Good luck.
Recently I have to develop on mobile phones using Java and I am planning to do the development on the following brands:
Nokia
Samsung
SonyEricsson
Motorola
LG
I've browsed the "developer site" of each company and looks like they all have provided their own SDKs for J2ME development.
I am really new to this field and I have a few questions:
Since they all support Java platform, why do we need additional Java SDKs?
What can I benefit from the SDKs?
What determines whether I should use the SDKs or not?
It all depends on how complex the application your want to develop will be.
Developing a basic application to run on that many different handsets is doable but complexity will increase exponentially with each advanced feature you add, especially if you want to target existing, old and upcoming devices.
What you also need to consider is that each manufacturer can support several operating systems and platforms.
Nokia has Series40 (3rd and 5th editions), Series60 (2nd, 3rd and 5th editions), Series80.
Samsung has at least 2 major versions of their own platform and the last 2 editions of Series60
SonyEricsson has 3 major versions of their JP8 platform (and JP7 too), Series60 5th edition, UIQ 2.x and UIQ 3.x
Series80, Series60, UIQ 2.x and UIQ 3.x are based on the Symbian operating system. Different versions of Symbian OS have used different JVMs and several companies have contributed JSR implementations.
Motorola has at least 2 major versions of their own platform and a couple UIQ devices
1 - Since they all support Java platform, why do we need additional Java SDKs?
The major problem of J2ME is fragmentation. For a variety of reasons (both good and bad, both technical and commercial), the Java promise of "Write Once, Run Anywhere" is largely considered utterly unfulfilled in the mobile industry.
Many functionalities need to be coded in a platform-specific way if you want the same code to work on many platforms at once.
Many J2ME platforms also add non-standard APIs, properties, configurations, "bugs"...
Most importantly, manufacturer SDKs are supposed to allow things like on-device debugging or MIDlet deployment over USB. They provide basic or extended tools that help on-device testing because that is an area where a generic WTK should typically be lacking.
2 - What can I benefit from the SDKs?
Very probably, yes.
Ok, so, most of them will only run on a Windows desktop computer but the SDKs themselves should be free.
3 - What determines whether I should use the SDKs or not?
Start with the WTK. When you realize you're trying to do something that is specific to the handset manufacturer, get the corresponding SDK.
One example: The WTK PDAPDemo sample application contains a rudimentary filesystem browser. It displays widely different results on different platforms.
As suggested by Pavel Alexeev, DeviceAnywhere is a great tool, assuming you have a proper test budget. Nokia also offers something similar but that is obviously limited to Nokia handsets.
Benefit from vendor-specific SDKs is only if you want to use vendor-specific APIs. In most cases Sun WTK would be enough.
As for testing purposes, I would not suggest to rely on emulators. You better try on-device testing. Nokia and Samsung provide remove device access for recent devices. And you can also try deviceanywhere.
I would do most of my development with the regular old Sun..err...Oracle Java WTK, and then if you need to do some testing, get the emulators/SDK's from those companies. Other than that I'd mostly avoid them though.
Built in camera functionality typically differs between different brands of phone and the API's provided can be very helpful when trying to do anything more advanced than take a simple snapshot. SonyEricsson phones for example will allow you to display a camera feed through a VideoCamera directly to a canvas which is very fast but does not not allow you to control how frequently the feed is drawn to the screen. In order to draw graphics on top of the video feed without excessive flickering you need to add the OVERLAY flag (1<<8) to the VideoCamera's initDisplayMode() call, not all brands support the additional flag.
For .NET guys - there is a Ubiq Mobile framework. Ubiq Mobile apps work on Android, iOS, Windows Phone and Java-based phones and tablets. This is rapid cross-platform development with .NET with cloud-based architecture. Getting started article: How to create simple UbiqMobile application with video.
My opinion is "QuickRecipesOnSymbianOS" is correct. It is very easy, simple and technical answer.
i need to build an app for blackberry that will change the background color for all apps
something like this:
http://www.thomson-software-solutions.com/html/screen_tinter.html
is this something i should do in java? i have no experience with programming for PDAs. which compiler would i use?
You would have to use J2ME (Java Platform, Micro Edition) with the RIM's API. To get started, you might want to pay a visit to RIM's BlackBerry Developer Zone. They have a development IDE with everything you need to get started.
You also must first understand that coding for mobile platforms is totally different from coding for a PC. What you can do is fairly restricted (by design, hardware creators usually don't want third-party addons to fault the device). I don't think your project is feasible.
I am developing mobile apps for some time in .NET and I was always wondering if the grass is greener on the other side (Java).
Thus, I would like to ask your opinion about which one you prefer for your mobile apps and why is that so.
The main advantage of using Java is the broader installed base. If you use Java, you are going to reach orders of magnitude more phones than if you use .NET.
As far as I know, .NET works exclusively with Windows Mobile phones.
On the other hand, Mobile .NET is easier than Java (IMHO), and that's partly because of Visual Studio IDE which makes life so much simpler than any other development environment on the Java World. For example, doing Form Based applications in .NET mobile is really straightforward and simple.
So, the answer will basically depend on what you are trying to accomplish:
Trying to reach to the biggest number of mobile devices: go with Java
Trying to develop an application for Windows Mobile devices: go with .NET
Trying to develop an application that will run only on a controlled environment (A single business) where you get to decide the devices it will run on: decide which device you are going to use and then pick development environment.
Keep in mind that if you are talking about Java for Android or Blackberry development, you will face the same issue of not reaching to a huge installed base that you will with .NET. If you want the huge installed base, go with plain Java Mobile Edition.
I can only speak for windows mobile development stay with .net.
Sun don't even release a JVM for windows mobile devices I have developed for windows devices using java and using http://www2s.biglobe.ne.jp/~dat/java/project/jvm/index_en.html as my JVM which was very good the author even responded to a feature request I made.
It is true that if you're going to develop for WindowsMobile, J2ME is not a very good option. More than likely your device of choice will not come with a JVM and if it does, it'll be buggy and slow. Also, forget about trying to integrate with with OS at more than a basic level.
Just to add to what others have said, Sun has made phoneME available and if you want to go that route and deploy your MIDlet and VM together that is certainly a possibility. It's just a lot of work at this point.
For .NET guys - there is a Ubiq Mobile framework. Ubiq Mobile apps work on Android, iOS, Windows Phone and Java-based phones and tablets. This is rapid cross-platform development with .NET with cloud-based architecture. Getting started article: How to create simple UbiqMobile application with video.