BlackBerry - is it possible to develop branded applications? - java

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.

Related

Converting an existing web app to desktop application

I saw some other similar questions on this topic here but they were not very helpful so I a posing this question.
What is the fastest way to convert a reasonably sized, simple web app to a Java desk top based client targeted for pc and mac? Unfortunately I can not share a whole lot of details about the app here due to various reasons. The most complicated UI in the app though is a page that contains a multi level threaded discussions (please see here for an illustrative example of what I am talking about.) The current web app is based on python so I can not re use anything from the server side code (dont think this is an issue)
I have never done any swing or awt or any other Java based thick client GUI work. My thinking is more or less defined by web based applications. I am capable of doing end to end web app development (including backend and decent UI using HTML, CSS and JS) using Java or python. For your answers please focus on Java solutions only.
So here are my questions
What is the best framework or tool I should use? I found some of the following tools on the web as part of my research.
Awt - does not look like this is a good choice.
Swing which I believe is bundled with regular Java SDK/JRE. - This may be my best
bet.
SWT which seems to compliment Swing in some fashion.
Griffon based on an article here. This framework uses Groovy ( I
have no clue about Groovy, btw) Adobe Air flex. Any open source
frameworks?
What are some of the other issues that I need to keep in mind? Some that I would like your comments on are:
How does the fact that it needs to be deployed on the client complicates things? Since we are using Java, I believe this to be a non issue. I am aware of the usual trade offs between a web based app and a desktop app (e.g. ease of deployment and upgrades etc etc.)
How easy is it to create a one click installer and bundle the app and the environment needed - eg. JRE etc?
The product needs to work on Mac and Windows. Does that complicate things in any way (Again, since it is Java I am assuming there are no gotchas but would like to be forewarned if there are any)
What is the framework or technology that may be good to have on the resume as a skill set?
My deadline is a max of 2 months - would that be enough for a reasonably simple web app given that I need to learn all of these technologies? I am just trying to get a sense here - I know it is most likely impossible to give an accurate answer - just assume I am smart enough and can pick up any unfamiliar tech stack fast enough.
Thank you!
GUI toolkit
Given "Mac and Windows", I'd say that settles my recommendation as "Swing" (perhaps with SwingX1).
I agree with your assessment of AWT. It does not support formatted text in any component out-of-the-box. It also lacks trees, tables (and other components) & people with recent experience using it. Note though, that it is also "bundled with regular Java SDK/JRE" just like Swing, it is just that it is older and less enabled than Swing generally.
If anything complements Swing it would be SwingX. SwingX is built on Swing and provides advanced controls that are not available 'out of the box' in the J2SE.
Swing and SWT are mutually incompatible - use one or the other.
I have no experience with Griffon.
Swing is the most used of the options outlined, so for getting help (ignoring other potentially important factors in the decision), it would be a good choice.
Note 1) Add SwingX if they have any groovy components that present threaded conversations easily, but I suspect a JTextPane would suffice.
Deployment
As far as deployment goes, that is a little more tricky than it seems. Many desktop computers do not come with Java as standard. Those that already have it, might have an old version.
To ensure a JRE of the right minimum version to run the app. is available, use the deployJava.js (mentioned, with links, in the JWS page below).
To provide a 'one click' launch experience for the user, look to Java Web Start.
Cross-platform gotcha's
Unfortunately, though Java is x-plat, there are plenty of things that programmers can do that stuff that up. E.G.
Not accounting for the platform default:
File encoding (file.encoding2)
Line break (line.separator2)
File separator (file.separator2)
Coding fixed size ('absolute layout') apps. that will be shown as different sized apps. on other OS.
...
Note 2. That is showing the property to use for each.
Timetable
Obviously I cannot speak for you, but I can tell you that I would have had no chance of going from 'which technology' to a 'deployable app' within two months.
Hope you're more capable than me! ;)
You said that you wanted a Java solution, but be aware that there are plenty of Gui options in Python, and you already have your web application written in Python.
Groovy is a different programming language than Java, but Groovy runs on the JVM. Do you want a Java solution or a JVM solution? I ask because you mention Griffon.
Assuming you want Java, I think your main options are Swing, SWT, JavaFX 2, and Apache Pivot. Oracle has said that they intend for JavaFX to replace Swing as the GUI platform of choice. That said, JavaFX 2 is in its infancy, and only a preview release is available for Mac right now. The upshot of JavaFX and Apache Pivot is that you could use the same code for your web application as your desktop application.
You can try doing so in small steps:
* As a first step you can create an applications with SWT and embed your application in a browser control.
* Then you should move pages and some controls from the web app to the desktop one by one.
In this way you can get a minimal application in hours :)
P.S. If you want an iOS app with this approach it's worth looking at this open source project: http://en.wikipedia.org/wiki/PhoneGap

What are the pros and cons of using webworks versus J2ME and vice versa in blackberry development?

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.

Web Interface or Graphic UI

Hey,
i've a simple question.
Task:
Program a backup system which can be used by server-, or desktop-systems. The backup system should include a graphical configuration and status view. The programming language should be Java.
Question:
Would you use a web interface, which will solve these jobs or would you create a GUI in Swing?
My thoughts:
- The web interface has the advantage that is is accessible from everywhere (server - configuration made easy without any additional software on the client side).
- The GUI has the advantage that it is more responsive than a web interface and will maybe look more professional on a desktop-system than, the web interface version.
Which solution whould you choose?
Thanks!
The desktop vs. web app discussion usually depends on who would use the application, and from where. If it's always going to be used by the person sitting at their desk (or at the desk of the server), a desktop application is a good choice. If the user may be remote a web application is the way to go.
Another consideration is deployment. Is this going to be deployed on one or two machines, or does it need to be installed / available to 10's, 100's or 1000's of users? Deployment and updates across hundreds of machines can be onerous for desktop applications, but a non-issue with web-based apps.
Generally speaking, you can give a much richer experience with a desktop app. In this case, however, "rich" isn't really a requirement. You're going to have a few buttons, perhaps a window showing a log of some sort, and that's about it. So from a usability perspective you can probably create a compelling UI using either method.
If deployment and a rich UI don't really factor in, pick the one that either a) you know well, so you can do a good job, or b) want to learn assuming you have the time.
Since the actual question you asked was "which would you choose", personally I'd choose a desktop GUI based on the little information provided in your question.
Yeah Bryan is totally right. Choose the solution you prefer, since you are the developer :)
I'd prefer the web solution, because I love to play around with these nice Web 2.0 AJAX/JS things. Also there are at the moment a few new Browser Developments, which will make it possible to use an webapp as desktop app.
Basically, it's really no matter which variation you choose.
I did serious Swing work in the past but I see less and less the incentive to use "fat client" technologies with today's web based UI (Ajax, JQuery, HTML5 and efforts like html5boilerplate.com to make them work on older browsers). The browser is the present and future of rich UI, specially as more software makes the move to the cloud.

Midlet v/s Phone Browser app pros and cons?

How do you weight the pros and cons between a Midlet and Browser based client/server app for a phone ...
What are the pros and cons of both...
And based on your experience what will you prefer to go in for and why?
I have listed some points based on which we can compare both feel free to add your own...
Rapid development.
Rich UI.
Mild data transfer between client and server.
Ease of use.
Portability.
Wide phone target audience.
Here's a great blog post tackling this exact issue. I used to work with the poster and know he's spent a significant amount of time on both sides of the fence, mobile app development and mobile web development, to have a well formed opinion on the subject.
APPropos? Are native mobile apps as supportable as mobile web apps?
I myself have only worked on the mobile apps side of things and there really isn't anything rapid or portable about the process, especially when your target platform is...all of them. However, mobile web apps will of course not allow you to supply as robust a feature set as a native app. It's all about trade-offs and concessions in the general mobile space at this time, and I think your taking the right approach to figuring out what is more important to your project.
The general answer is: It depends. Without knowledge of the goal, is it hard to suggest the road to it.
What type of application are you going to make?
What is most important? Performance or rapid development? Which features do you need? Database, inter-client communications? Do you need specific UI-elements, which is hard to create on a webpage? Do you need it to be portable? Which devices do you want to target? And a lot more questions...

Java marketshare: what version of Java runtime do most people have? Do I need to use Flash to get 90% possible marketshare?

My friend and I are planning to build a simple chat client to let people in a (physical, real world) room chat with each other (people chatting over the same wifi network, possibly pinging some external server to organize things by the external IP address of the wifi network). Partly we planned this as a chance to play around with Groovy, which we haven't done much with. But then I thought - damn, how many people have the Java 1.5 runtime? Maybe this is kind of thing where Flash would be better (when I say "Flash" I mean "Flex")? I hate ActionScript and I have very little experience with it, and I've no real interest in using it, but I'm thinking, if we want 9 out of 10 of our friends to be able to use our software, Java is possibly not the way to go?
My concern is in particular with the demographic we have in mind, which will tend to be freelancers and artists and individuals, rather than people at work. I'm aware that Java still has a decent overall market share, but I'm under the impression that its use is heavily concentrated in the computers that people use at work. Folks who don't work at corporations may not have a modern runtime?
I then decided to look up Java market share. It is surprisingly hard to track down info about specific JREs.
There was this on stackOverflow, but its focus is on RIAs, which isn't what I'm talking about:
What's all this business about Flash, Flex, Adobe Air, Java FX and Silverlight?
And then conversations like this make it sound like Flash is the only reasonable choice to make if you want people to be able to use your software without jumping through a lot of hoops:
http://forums.java.net/jive/thread.jspa?messageID=317749&tstart=0
This seemed like a reasonable summary of Java versus Flash issues:
Client Java vs (Adobe) Flash for web applications, what to choose and when
I found it surprisingly hard to track down actual market share data on particular JREs. And I found no easy way to find out if folks who with modern JREs installed are mostly using their computers at work.
So I'm open to hearing some anecdotal information here. If we built our simple chat client in Groovy/Swing, would our target demographic be able to use it? Is Flash the only reliable way to go here?
If portability is your goal, why not go for a JS only approach, perhaps using one of the COMET styles of push? Here's an article to learn more:
http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications
If a JS RIA isn't what your after. Then Flash/Flex are your next best bet. I'm usually biased towards Java as a technology, but based on your target app and audience I think you'll get more joy using a Flash-based technology.
Adobe understand RIAs better than Sun, which was kinda demonstrated by some high profile Java 2D devs moving to Adobe in 2008/09. Plus with recent Flash Player developments you'll get your app onto more mobile devices.
Obviously server-side in Java ;-)

Categories

Resources