I am used to programming in Java EE but right now I am being assigned to Java ME project. From what I am reading all those ME restrictions are quite painful. Do you have any tips on how to deal with such a crude language? Are there are any good libraries which might give a higher level of abstraction?
I am also looking for tips about developing tools or strategies e.g. tools like maven (I mean tools without which you can't imagine working). Are there are tools/approaches which you must know about in Java ME?
There are so many things to discuss here, you could write a book or two about the topic!
First of all, realize that "Java ME" is an umbrella term that encompasses a variety of Java environments, some very limited compared to Java SE, some nearly as capable. However, when most people use the term they're really referring to the limited side of things -- the CLDC (Connected Limited Device Configuration) and the MIDP (Mobile Information Device Profile). So let's assume that's where you're going.
The biggest problem you're going to face as a J2EE developer is the sheer LACK of APIs in a MIDP environment. Also missing language features -- no enums, no generics. Basically you're dealing with a subset of Java 1.3, which is a huge step back for you. The collections classes aren't there, for example, so you end up using the old-style Vector and Hashtable classes a lot. Or you end up using device-specific API extensions at the cost of portability.
The good news is that the NetBeans tools is pretty good for MIDP development, they've put in a lot of good features. You can also use Eclipse, there are some good plugins for that. The tool support is there, including ant tasks and so on.
There's lot of material on the web to get started with Java ME. Read some of my Java ME overview material (which still refers to Java ME as J2ME). Then figure out what platforms you're targeting. If you're doing BlackBerry stuff, for example, you'll want to learn and use the BlackBerry APIs and not MIDP.
There's definitely a learning curve, but you'll adapt quickly enough.
Related
I have been looking framworks for developing mobile apps and i have been told to work on rhomobile framework but i did google and i found very limited resources and tutorial... my apps are bit complicated and at this point i am not even sure rhomobile framework is good choice....
do you guys think it will worth investing time in learning?
any suggestions?
Thank you,
It depends on your requirements. If your application is data centric then I highly recommend Rhomobile, and If your application has less data and more static page then better use Native frameworks.
You can quickly start with following resources http://rhomobile.com/resources/
If you have some knowledge in ruby it is not very difficult to start using rhodes, but it will always depend on your requirements and on how much time you want to invest to develop apps for different OS.
I have found Rhomobile very easy to follow. Of course it is limited as it is a relatively new framework, but you can get very good help on their Google Group.
I have developed on iOS and Android, and I must say I hated Objective C. Android with Java was more familiar and easier for me, but still, it is not compared to doing one app that works for all (even though you have to make dome minor tweaks for each OS).
One thing I did have problems developing in Rhomobile was working with maps. Rhomobile's Maps have different limitations depending on the OS of deployment.
Anyways, specially if you are working by yourself, I would recommend experimenting with Rhomobile. I believe you will get your job done faster that developing for each one (Objective C is a nightmare!)
One thing I love about Rhomobile Rhodes framework is their support for those old Symbian S40 phones, although they are not the mainstream phones today but still those platforms need to be supported in many enterprise apps
I have a C# app that I've managed to get working with Mono and running on OS X. The application itself runs just fine, but it doesn't really look all that good when run on OS X. The button fonts look jagged, and many of the default features that are there for the Windows 7 version aren't present. To me it sort of looks like a Win98 application with an OS X top border taped to it.
I'm looking into possibly learning Objective-C so that I can write 'proper' OS X apps, but for the moment I'd like to be able to get my projects working on an Apple without having them look Frankensteined together.
Is it possible to convert a WinForms app over to Cocoa? Is Cocoa the correct interface to use?
If possible, what's the best way to go about it, and do any of you know of a good tutorial/writeup on the process to get me started? It'd be nice to see something that actually shows the process being done. I learn far more from example code along with a short explanation than I do from a generic article.
Thanks again!
If you want to create a native looking OSX application, you are correct that you want to use Cocoa. If you still want to use C#, you can use MonoMac.
MonoMac allows you to build your GUI natively on OSX (in fact, using the Interface Builder shipped by Apple), but allows you to write your app in .Net/C#. This way you can continue to use your existing application logic and only have to change the GUI code.
It's pretty much universally true that a ported app will always look like a ported app. Even large companies with huge budgets can't pull off anything better (I cite Adobe - what a mess).
Slapping a Mac face on a Windows app port will show its seams. If you want the application to behave like a native application (and take advantage of the performance-related goodies the platform offers), the absolute best approach is to use the architectural documentation, specs, and requirements I know you have - conscientious developer that you are - to adapt the design to the native platform. That's the Cocoa Frameworks (the API), which are written in Objective-C (the language).
There's quite simply no other path that doesn't end with a crappy-looking port that's riddled with bugs and behavioral problems born of the porter's insufficient familiarity with the target platform. This isn't just limited to Mono/C#-to-Cocoa/Obj-C. The opposite is just as true. Even Java-for-PlatformA-to-Java-for-PlatformB ports of desktop apps suffer these problems. Start with a solid architecture and build for the platform if you want the best user experience.
That said, you're already a step ahead by realizing this and wanting to do better. Bravo! :-) Though I don't know of any tutorials for this path, I'd suggest even that's not the correct approach since you indicated you're looking for quality. Avail yourself of the many Cocoa books and many more online communities (like this one) and learn the platform before committing to your Cocoa-adapted architecture and code base.
Update based on comment debate
To be clear: I'm not saying there's no way or that there's no tool out there that makes it possible. There're actually plenty I've seen but don't recall and won't bother googling. My point remains: the OP is concerned with quality of native appearance (and I assume behavior and possibly performance) and porting tools / translation layers don't achieve this due to inherent differences in the platform's architecture and user experience idioms. The OP suspects it might be best to learn the platform and build specifically for it and I'm agreeing. Your opinion may vary. Have at it.
I see a lot of talk how HTML5 video tag will kill Flash. But while video is the most widely used part of Flash/SL, it's only a small part of their technical abilities. For instance you can write a game using full 3D graphics and socket connections in Flex, and serious business applications, etc.
Is the thinking that Javascript will kill those parts of Flash/Flex/SL? Because while that seems feasible now for even quite rich web-apps, what about any kind of high-performance app like real-time graphics?
You can do some pretty cool things with HTML5, Canvas and the like. Check out the Google-hosted http://www.chromeexperiments.com/ (which, really should be named HTML5 experiments, as most run fine on HTML5 browsers). You can get an idea of what is possible, including 3D rendering, complex games and some pretty amazing animations.
(source: chromeexperiments.com)
Sketchpad by Michael Deal
basically, this question has been around already.
The answer in short: no, HTML5 will not replace anything. HTML5 will however offer a standard for features currently only available through plugins. Once HTML5 is released, which is scheduled for 2022, it will be a great thing. Still, even by then, if IE survives, I doubt it's support will be outstanding.
There has been a very similar question to which I provided a rather lengthy but detailed answer: should web developers learn flash
My personal opinion about anyone who thinks HTML5 will replace 3rd party plugins is, that they lack basic understanding of HTML5's role or sufficient knowledge about any plugin and have little if any grasp of how the web evolves.
Yes, the day HTML5 is sufficiently spread for large companies to rely on it, many of them will be able to replace 3rd party plugins within their web applications. However, as pointed out in my other post, the web is constantly evolving. HTML5 does not provide new features, that weren't available using plugins. And HTML5 does not provide all features currently available using plugins. New types of apps, services and content distribution mechanisms will arise. Also, as long as JavaScript stays fully dynamic, JS runtimes will never be able to provide the same speed as runtimes designed to run bytecode generated from statically typed languages.
Personally, for the client side, I basically only target the Flash Player, because to me it is the most convenient platform. I am not afraid that HTML5 might kill flash, for a simple reason:
Until HTML5 is really usable and largely supported through sufficient user adaptation, it will take several years. In the same time, all major plugins will continue to evolve, as well as their eco-system, including developement tools, cross-compilers and compatibility layers.
Today, you already need no knowledge of HTML, CSS and sometimes even JavaScript to create webapps, using GWT, qooxdoo or other tools.
HTML+CSS+JS represents nothing more than a platform that more and more languages are able to target. Using reasonable amounts of abstraction, one will sooner or later be able to develop apps in a totally platform agnostic manner, causing virtually no overhead for the lion's share of all apps: GUI (including localization, validation etc.) and application logics.
In the end, there's no reason to get excited. Currently, both Flash and Silverlight exceed HTML+JavaScript implementations in speed and features exposed through the available API. That is, why people use it. Altough unlikely, some day they may become obsolete. In this bright, bright future, far, far away, I will be happy to compile my sources to run in a JavaScript interpreter rather than on AVM2.
On a vaguely related note: check out Haxe.
There are many high-performance apps with real-time data streaming and graphics in production today that have been built with Flex. You can see some examples of these in the flex.org showcase. As always, deciding on a technology comes down to what is being built, who it's being built for, and who is building it. Flash, Flex, Silverlight, HTML5, etc will all coexist.
The discussions I've been part of on this subject, pretty much always seem to come to the conclusion that, while the HTML 5 standard will be a a great thing, once it's in place. It will by definition be a standard, standards take a long time to change, therefore innovation will be driven largely by plugins like Flash and SL.
And yes you can do a lot of what Flash and SL can do with Javascript, however Flash/Flex has the strong point of being used for desktop installed Air applications, and Silverlight has the similar thing with their "Out Of Browser" functionality. These are things where they clearly have the upper hand over Javascript.
At the end of the day it's not a matter of who will kill who, but rather which tool is the right one for the job and what skills does you / your development team have.
That's my 2c anyway...
Did Flex replace HTML forms? Have HTML forms killed Flex? Has C++ replaced C? Has Ruby or Lua or Python killed Haskell or Scheme or assembly?
Seriously, what is the obsession lately over whether HTML5 will kill plugins? Is it so hard to imagine people using Flash for content that needs to stand out and maximize expressiveness, and using HTML5 for content that needs to utilize standard metaphors and maximize accessibility?
In other words, no - the thinking among thinking people is not that the HTML5 stack will kill Flash/Flex/SL. If things work as they should, the plugins will keep innovating what you can do with proprietary techniques, and HTML will keep taking the most successful of those innovations and standardizing them. And if things don't work well - if a plugin fails to innovate, or a new version of HTML is done badly, then they'll fade into obscurity as developers stick with whatever solves their problems.
I think it depends on the authoring tools and the efficiency of the browsers. It is reported that the upcoming Flash CS5 export content directly as a HTML5 canvas. So the canvas can be a quite reasonable flash substitution.
For "high-performance app like real-time graphics", see WebGL. Mozilla and WebKit already have experimental support for WebGL, which is based on the <canvas> element.
For sockets, there are WebSockets, which are also experimental in some browsers.
For background processing, which can improve the user experience, there are web workers (experimental again).
A lot of experimental stuff, but they are improving them constantly, so at some point, even without an HTML5 standard defining them, we might see games specifically targeted for a certain browser (actually, there is some proof of concept but I can't find the link right now).
I think JS already has killed Flash/SL/JavaFX. JS is the most used language on the web, so just add a few features, enhance some tidbits and voila. Flash is alive because of videos and games, no serious website uses Flash nor any other RIA. Just wait, it's going to be a hell of a ride the next few years.
I'm mainly asking this to professionals who know the playing field of professional developing. Is it worth it to learn and develop skills in Silverlight?
I know that penetration for Silverlight is obviously low in comparison to Flash but Silverlight seems lighter and a more cutting edge technology.
What are some of the benefits Silverlight has over Flash?
Is there a lot of work for Silverlight developers (of course combining them with ASP.net)?
Thank you very much for all the responses. :)
Edit: I program mainly in C# so there will be an obvious plus side to using it.
Also, how reliable are these results: BubbleMark
It's a huge topic and you can read articles all day on Flash-vs-Silverlight-vs-AJAX.
I use Silverlight and was completely over the moon when it was released due to the ability to employ the CLR in browser based applications. Javascript/DHTML development drives me nuts and for me Silverlight was my way to escape its clutches. As far as Flash goes my very brief foray into it found ActionScript to be more painful than Javascript but that was years ago and things have undoubtedly improved since then.
Basically if you're using .Net for your back end then it makes perfect sense to use Silverlight for the front end. It means you only have one development environment and language to deal with and where appropriate you can reuse a lot of your back end code on the client.
In practice it's not quite that easy and my experience has been that there is a lot of resistance in user land towards Silverlight. The main bone of contention is generally that the cross browser and operating system support is not good enough. Users that employ Opera or use Linux or PowerPC Macs can't use Silverlight (Moonlight isn't there yet). Those users are generally vocal ones.
If you know all your users will be on IE/Firefox on Windows/Mac Intels or you have a compelling application that users will change their set ups for then Silverlight is almost certainly your best option. If you have an application that you want to hit a wide range or disparate users you may need to weigh up the options a bit more.
The fact that Microsoft has thrown their weight behind Silverlight as the Web Application Framework of choice gives it a pretty decent chance of becoming widely used (though certainly no guarantee).
To position yourself in the most versatile way, though, you might want to consider first learning about the capabilities and limitations of both systems and then learning how to implement with both.
There will probably be many projects done with Flash, and many done with Silverlight. If you can program to either, you will be in a good position. If you are able to provide skillful assistance in deciding which one is best for a given project, you will be in a great position.
I tried it and did not like it. I didn't like the split development environment, xaml, or the limited install base and platforms it runs on. The IDE and platform itself still has a ways to go before I would consider it for use in a production environment.
I've been developing with XHTML, CSS and Javascript for about 4 years now.
I love it a lot and hate it a little. I've looked into Flash and Silverlight a bit, but as a developer, I'm not too keen on them.
One reason is that they lock you into a vendor and generally, into using that vendor's tools. E.g. Adobe Flash or Microsoft Visual Studio, etc.
Also, Silverlight seems to mix content, layout/styling and behavior and into a single markup language, whereas I like the XHTML way of separating them out in code, but bringing them together in the user's web browser.
I also applaud the usability of the web, e.g. back button, hyperlinks, etc. which are set-in-stone standards that people are used to dealing with.
However, I'm seeing a lot of industry support for Silverlight and Flash. As far as .NET Developer jobs, I'm seeing less jobs for front-end/.NET developers and more jobs for Silverlight/.NET developers.
Will HTML developers still be employable in the future, or should I consider moving to a proprietary platform such as Silverlight?
While Flash/Silverlight skills may be worth developing, I think you will find that general web development skills will still be required for some years to come. Mobile apps in particular seem to place more emphasis on good, basic web design without dependence on plugins and or client-side code. Eventually, I would expect web standards to evolve to subsume the best (or at least most used) features of proprietary plugins. The web, at least, seems to be a place where people tend to favor solutions that maintain independence over lock-in to specific vendor technologies.
No, I think that idea will never fully catch on. The problem is really about the platform being developed on.
Look at how accessible the web is. Almost any machine can get on the web. My phone, my iPod, my laptop, my 11 year old PII machine, my gaming tower, all can access the same web.
The devices I have are not the limit to what can reach the web either. I think just about every gaming platform and cell phone can get on the web, as well as thin terminals running any OS imaginable. I'm sure there are others also.
The big thing looks like it's going to be the mobile market in the next few years. Some mobile devices can run flash, but it isn't used much because of the poor support & performance. The only way that the mobile web can work is by using pure standards based solutions, because that's really the only baseline that can be trusted to exist.
No matter what proprietary technologies come out, I can always rely on the fact that my XHTML pages will still render successfully on whatever device decides to access it. The same can't be said for flash or silverlight.
At the same time, I can also guarantee you that there will be a bigger market for flash and silverlight because the web is becoming more "media rich" in some niche markets (YouTube, Adobe Air, Hulu, Google Gears, etc. to name a few examples). There will absolutely be a market for it, but I wouldn't say it will defeat XHTML and web standards because the web is constantly being redefined.
No matter how much Flash or Silverlight try to take on, the technology will move so fast that the only baseline that I think will remain will be standards like XHTML and CSS.
Flash has been around for years and still hasn't taken over. I think that is one good example of how hard it is to replace XHTML.
Go for server-side development of any kind, but I wouldn't become a Silverlight or Flash specialist.
<CrystalBallMode>
To be honest I can't see it happening. Other than the reasons mentioned by tvanfosson and DanHerbert, the XHTML + CSS + JS stack just grew mature enough so that things like AJAX and jQuery make pretty much all the lightweight client side stuff easy with these tools (as opposed to things like streaming video, heavy computations or sockets etc.)
Common technological inertia will just guarantee that the existing things will stay around. People are much more likely to use something that has been around for a while and has been extended to meet the latest requirements than to use something totally new. Of course there are great paradigm shifts every now and then like the native to managed code transition but I don't see that happening with Flash or Silverlight.
</CrystalBallMode>
My hope is that what comes out of all of this is a new standardized web platform truly suited to building the web applications that people want to see with tools that developers really want to use. I see all of the effort going to trying to shoehorn these legacy web technologies into the "Web 2.0" model and I just wish that this effort could go towards making a truly revolutionary "Web v.Next".
Don't get me wrong, I really like what jQuery is doing to make Javascript client code easier, but it's still Javascript and my personal preference is to work with strongly typed languages with productive development tools.
In the meantime, I think tools like Silverlight and Flash have a lot to offer and help you do things more easily in some cases than in other web technologies, and there are some things you simply can't do any other way. But I don't think Silverlight or Flash or any other technology is the end game, just a step in the right direction.
Consider for a moment that you can manipulate a web page using Javascript, (X)HTML, and CSS with a great deal of overlap in functionality and yet ALL three technologies remain in prominent use today. The reason for this is because all three languages are different tools meant to solve different problems and no one of them can serve as an adequate replacement for the other.
Its the same thing with Flash / Silverlight vs these existing web technologies. In fact, I work in a dev shop that builds Flash based e-learning. One of our current products was originally built to use a purely Flash-based solution for navigation, etc. However, as the product has continued to evolve we have actually moved a lot of the functionality from the Flash-based e-learning module and into regular html pages.
In other words, I don't think that we'll be abandoning the current tools that web developers use any time soon. For the most part I see Flash / Silverlight as additional tools that will solve particular problems better than we were able to solve them previously.
Neither one is going to win out anytime soon. I expect which one is used will depend entirely on the purpose for many years to come.
The reason you're seeing so many job offerings for Silverlight of late is because it's a relatively new technology and just recently gained some momentum.
Though, I do expect Silverlight to make quick work of Flash.
I sure hope so. And yes, I think they will. There will be some development on legacy (XHTML/CSS/JS) apps for re-tuning purposes, but I think there will come a day when new apps are simply not created on those platforms.
Mobile phones are the issue right now. Flash isn't available on many of the major phone models. And their browsers are all over the map. Luckily there's Webkit (iPhone and G1).
If Silverlight makes it to a web platform then it will be a nice viable alternative to the hodgepodge of technologies that are currently in use. FYI, Microsfoft says Silverlight on Android is very possible. On the iPhone, hard to say, Apple is weird about such things.
AOL recently created a RIA version of it's email client in Silverlight. Looks nice and there's no Javascript errors to worry about. From a developer standpoint, that's huge.