I'm looking for a lightweight physics engine for Android. I don't want it to do any rendering itself. It needs to be easy to use, fast, and have some tutorials/api docs.
I had a similar problem a while back ago and eventually decided to go with JBox2D: http://code.google.com/p/jbox2d/.
I agree that docs are not very good for this particular port, however I find the original manual very useful (despite the fact that it's in C++): http://www.box2d.org/manual.html.
Furthermore, JBox2D comes with something that is called Testbed -- a simple GUI application aimed for testing. It has a bunch of examples, which should be enough to get you started.
Libgdx has JBox2D built in and is cross platform (Android, Java Desktop, GWT Web) like Unity, tho it's free and open source. Not sure why you don't want the library to do rendering for you, but you can strip out anything you don't want.
Related
I have written some basic applications using J2Me and felt that getting things done in terms of UI/UX were a night mare especially with blackberry OS 5. I then started playing around with Webworks and found it to be better and faster however i keep getting told that it is better to stick with J2ME. Which one is a better choice? Is one limited in features than the other? What will RIM support for the long term future?
This is a decision to be made for each application.
How well do you know HTML, Javascript, and CSS? How much device integration do you need? How graphics intensive will the application be?
HTML et al have a much lower learning curve than J2ME and the RIM APIs. You are missing some of the more functionality that integrates deep into the phones abilities. But you have a distinct advantage in that anything that you find missing in the Webworks libraries, you can write as Javascript extension in Java.
Webworks itself is limited to the blackberry platform, but HTML, Javascript, and CSS are practically universal. It's simple to turn the application into something that will work in a web browser. Just take out Javascript calls to any blackberry.* apis (or wrap their use in blocks like if (blackberry) {), and redirect anything in an XMLHTTPRequest to be proxied through something on the local server. I'm doing it this way for a Playbook app I'm working on. It's nice that I can show others that don't use a BB the functionality of my app.
It's probably pretty easy to take your Webworks app and alter it for another framework like Adobe AIR or PhoneGap (I haven't tried, but intend to at some point).
From experience, Webworks seems to be easier to develop in terms of UI. But in terms in functionality, there isn't much. I don't know if they've changed this, but before, if there wasn't specific functionality in Webworks, you could create your own by porting the Java code over and creating your own extension.
I would say that using J2ME, would be the better choice if you need more integration with device functionality, rather than UI.
I've been developing in Java Swing for a while now, and I'm starting to feel that Swing-based desktop applications are feeling a little stale and are tedious to develop.
I'm seeing new applications that look very sleek and modern, like TweetDeck and Synthesia (a piano game). Despite the wisdom in Haase & Guy's "Filthy Rich Clients," I imagine that writing applications like these in Swing would be quite a chore.
Presuming that desktop applications won't totally disappear within the next 5 years (or that the division between the web and the desktop will become seamless), what UI languages and technologies should front-end developers be exploring to keep current? What's the next big thing?
Microsoft's WPF is probably one of the newest, coolest technologies out there.
It allows you to make much better looking GUIs.
You should also look into some of Microsoft's Expression products. They let you put that extra flare into your GUIs.
I'm not sure there's "the next big thing" in desktop UI development. If anything, "the next big thing" is a multi-touch based interface ala popular tablets and smartphones. Given that, I think it might be smart to learn how to create multitouch UIs by downloading a sdk for a mobile phone or tablet that supports multitouch.
If you like Swing, Take a look at Google GWT.
It is like Swing for the Web, well almost.
There will always be a need for OpenGL/Direct3D developers, but that might be further down than you're talking about.
On the Windows side WPF and Windows Forms are available.
On the Mac/iOS Cocoa is the way to go.
On Linux there's a few options such as GTK or QT.
You might just want to bite the bullet and learn some HTML5/JavaScript though. I doubt that's going to go away any time soon.
I'd suggest looking into Flex. It's much more interesting to develop than Swing and b/c it's Flash it can run in a browser or on a desktop.
Java still works fine. You simply replace standard controls with images and use image states to change the look on mouse overs and clicks.
I would also suggest WPF as another UI framework to get under your belt, because it does afford some pretty powerful UIs in desktop applications (and most of what can be one in WPF is translatable to Silverlight for webapps).
On the flipside, instead of looking for the next new UI language or technology, I think you may be better served looking at UI from a usability standpoint, and tracking the trends currently making waves.
As an example, one of the paradigm shift I'm seeing in UI development (mostly on the web) is the switch to making important things bigger and less important things smaller - including yes/no buttons in a dialog. I'm still warming up to this idea because it flies in the face of a consistent button look to show users their options.
Instead of providing options in a world today where we are constantly making decisions, the goal of this newer UI look is to breadcrumb the happy path. If the user decides they want to do something different, they can, but the UI is going to make the user put in a little effort and read the fine print.
Another example is flash-highlighting a recent change a person has made (SO does this, but I forget the term used to describe this effect) when coming onto a website.
Lastly, and this is one of my favorites, the shift from an administrative/user view (also mostly in the webapp sphere), to an ad-hoc WYSIWYG editor...Flickr is a prime example of this, where you can change captions on a picture by clicking on the current caption and editing it inline, without the need to go to a separate admin view to edit these values.
Is anyone else seeing trends like these that are interesting and new?
You've been programming in Swing for a while and you only just started feeling it looks outdated? :)
Swing looks like crap, no matter what look-and-feel tricks folks do for it. It actually put vendors of Swing-based desktop apps like ourselves at a disadvantage because of how shiny and pretty WPF stuff looks.
If you want to stay in the Java realm, I encourage you to try out SWT and JFace. You don't need Eclipse for it. But it's a much better looking system with a much nicer API.
If you want to go for attractive, WPF is your friend. You're limited to Windows and can't use Java (both showstoppers for me), but you can't ignore the aesthetics benefits of that SDK because it is so tightly bound to recent versions of Windows.
I think the point of the book you mention, and most of the answers here, are that most languages give you the tools, (or enough rope to hang yourself ;) to throw out the basic ugly controls of ANY OS you are on, and paint whatever user experience you want to. Yes it is tedious to skin or otherwise manually take over the visual representation of the controls in a UI, but if that's whats important to you, then you'll do it, and possibly be rewarded for it. Or castigated for breaking the "platform UI standards".
I know Java apps can be run in Android. But what I want to know is this: I have a perfectly normal Java app and I want to port it to an android platform. What changes would I need to do to my app in terms of GUI and other code to make it usable in Android? I know Android uses XML file to control the look and feel of its app. So would I need to change my GUI completely?
I just want to know the general overview of how porting may be done. If anyone could point me to right resources, that would be great. Also, for your info I'm a newbie to developing android app, so please be patient with me :)
Update: Both very helpful answers. Thank you!
The short answer is that you would simply rewrite all of the GUI from scratch, for Android. It simply uses a completely different UI framework. While basically all of the core Java libraries are there, Swing and AWT libraries are not.
If you are looking to translate parts of it automatically, I don't think there is any such tool. You're going to be building a brand new Android GUI.
And really, that makes sense. These frameworks are serving reasonably different platforms and needs (desktop vs. phone). You probably need to be redesigning your app quite a bit to go from a desktop to a phone.
Good news is the non-GUI parts ought to work as-is with no changes, unless they do something unusual. You may have to package third party libraries into your project if they are used by your code.
I expect that it will be a great deal of work to do the porting, as the way that your application works with Android will be different.
You will also have some issues, perhaps, with the fact that not everything in java is supported, as it is a mobile device, but does more than JavaME.
It would help if you could explain a bit about the application, as how much it needs to interact with the user or any other resources on the device will determine how to port and how much work is involved.
Your best bet though is to see about learning to program on the Android, and there are several good books on the subject. I got one from Manning publications that I found helpful.
You may want to look at the comments in this article, as I think it would be a good starting point for you on what may need to be changed:
http://www.anddev.org/problem_in_android_project_conversion-t1633.html
I've been asked to look into the development options for BlackBerry. My client wants to build an application that represents their brand. I realize that there are different techniques for doing development and the Java/J2ME approach is probably the most powerful.
Does anyone have experience with building branded applications, or have screenshots of BlackBerry applications that push the envelope in terms of user interface/experience?
I'd also like some feedback on the impact of the techniques in terms of experience. I'm sure there are various drawbacks to approaching an application from the branding angle, but I'd like to highlight these to my client.
The maker of PodTrapper (my favorite BlackBerry app), posted a great writeup on his experience here: http://www.versatilemonkey.com/story.html
One interesting thing I learned was that the framework actually makes you rewrite a lot of the display elements from scratch. So, yes, it's pretty easy to brand an app as your own (too easy).
I'm currently developing a blackberry application for my company. It's heavly branded (uses the company logo and colors from our cooperate identity). The blackberry api delivers many methods to display custom content. Personally, I see no problem in it.
Just set up a sample enviroment (it's free) and start developing.
Haven't seen anything about it here but it seems to solve one of the problems with GWT - the fact that you have to write Java code to generate your GUI. Instead this software allows you to design the GUI using drag-and-drop tools - a WYSIWYG interface.
I'm not trying to sell the product, by the way.
I just want to know whether it works as advertised, is effective, easy to use, etc?
Anyone have any experience to answer these questions?
GWT-Designer is now freely available as the product has been acquired by Google. http://googlewebtoolkit.blogspot.com/2010/09/google-relaunches-instantiations.html
Google will improve the product which is already quite good.
I don't think that the lack of a GUI editor is a problem with GWT. Consider HTML, there are plenty of WYSIWYG editors for that (like Dreamweaver) but most experienced web designers don't touch that stuff with a barge pole, they hand code it. Not because they're masochists, but because they want control over the source, they want to make it clean and readable. Coding is a scientific artwork, best left to Human Beings ;)
I tried GWT Designer very early on, and I found that it was fairly poor (and only worked on Windows because it had some dlls that went along with it), but things may have changed drastically since then.
I'm using GWT Designer for my Capstone project. I did start from scratch, and it worked quite well. I'm no fan of WYSIWYG software, so I was pleasantly surprised. Here's a link to a post I did on it:
http://benarchie.blogspot.com/2010/12/gwt-designer.html
GWT-Designer is getting better all the time. Give it another look some time, it's catching up to things like visual studio in my opinion.
Personally I like GWT Designer for Eclipse and it is free.
It is a rapid development tool. Not a solution for non-programmers however it will accelerate a Java coders ability to learn how to use the GWT API. Once you learn the tool it will reduce coding time.
I found it necessary to frequently switch between code and WYSIWYG editor to get things exactly how I wanted them. The two editors work well together. You will still need to refer to Java Docs to gain a full understanding. Most of the Java Docs have excellent Java and UiBinder code examples in them which are ready to cut and paste.
Creating GUIs in UiBinder is definitely the way to go because it simplifies the hierarchical nature of laying out GUI elements. The API is missing some information about how to hand code in UiBinder however between GWT-Designer, Java Docs and Google, you will find an answer.
The built in Jetty web server also simplifies deploying and testing on your local machine. I was able to make small code changes and see the effect in the web browser immediately.
Try these tutorials.
http://code.google.com/eclipse/docs/gwt_uibinder.html
http://code.google.com/webtoolkit/tools/gwtdesigner/tutorials/stockwatcher.html
I've tried GWT Designer recently. It still looks poor. If you don't want to lose flexibility, I would recommend to use GWTLab
Just tried it then. Most of my ui.xml files wouldn't open because it doesn't currently support #UiField(provided=true).
The ui.xml files that didn't use this feature would often crash with things like UnableToCompleteException.
Maybe if you started from scratch using designer you might have more luck.
I had a year's subscription but did not renew it, being a bit disappointed with the product.
1) The designer injects all Java code adding creation/property setting/event handling to the module you are building in a most unecomic way. Additionally, it is pretty difficult to modularize the application. Compared to Flex, for instance, the number of lines of code gets easily double or triple in a module and seeing the forest from the trees is not easy.
2) Web applications I built only a a couple of years ago CEASED WORKING possibly due to changes in Javascript engines. That was something I did not expect and is very possibly GWT's fault.
3) The GUI designer needs A LOT of CPU power and so does the build phase.
The concept is nice, however, I admit and GWT designer is the only of its kind. The feeling of difficulty in modularizing may well be my lazyness.
EDIT: Shortly after I wrote the above comment Instantiations/Google introduced the UiBinder concept which makes a lot more sense than the original amalgamation. Now it is a lot more professional.