01-24-2009 04:33 AM - edited 01-24-2009 04:35 AM
No, you don't need to understand framework core language.
You need to get a solid understanding of basics of the blackberry application architecture.
And after that make your understanding better and more complex towards to new knowledge areas.
If you are trying to write a complex application without understanding its nature - it is just wasting time, but not a learning. In this case you get nothing except of working, complex and inapprehensible code.
01-24-2009 04:57 AM
I agree, thanks.
But for real, this Java is proving a bit of a challenge.
It's not the BB architecture I am struggling with, as the API is well documented. I am stuck at, "How do I USE the API?"
I am extremely excited about writing apps for the BB. I have no doubt I will conquer Java's quirks soon, but for now, very frustrating.
Here are my observations so far, in case anyone is actually reading this except you:
1. The process to develop, build, debug, deploy is painfully slow. It really sucks to be honest.
2. The docs on this site are scattered.
3. There is a serious lack of tutorials from RIM. We should not have to struggle like this. As a programmer for many , unfortunately, many years - this is proving as difficult as Pascal was back in the day. lol
4. The IDE is horrid. Want to remove a workspace after the debugger was closed hard? You are in for a ride. You will need to remove the JDE and all associated files before your next successful build will simulate.
5. Eclipse's plug in is also very buggy.
6. BB's download section is entirely not EU friendly. Have to log in each time, agreeing to same terms.
7. Versioning. As a fairly new BB user, if I was not proficient in code, the versioning system currently in place would be absolute jibberish. You (BB, RIM) want new users to write code, correct? Of course. But, if you threw together a focus group of average users with average IT skills, you would be highly disappointed with the ratio of users who decide to pursue app development vs those who give up.
8. JDE memory consumption. It's a memory hog.
OKAY.... that is for any BB staff. That being said, still, I am glad to be a part of this board, and hope to see some of those issues resolved. As any of us, I could go drop 2 bills on an iPhone, but the BB is much more productive in a business sense versus entertaining functionality - thus, I will pursue your platform.
Java will be a piece of cake, it's the points above that will prove challenging.
My honest opinion, as a newbie here.
01-24-2009 08:18 AM - edited 01-24-2009 08:32 AM
I'm not advocating ignorance but for an experienced programmaer java is less likely to generate strange
errors- the JVM avoids really mysterious problems you encounter in unchecked environments.
It may make sense to progress to stepping through demo/sample code in the debugger reasonably quickly.
The framework concepts aren't all that novel and even the GUI isn't much different from message
loop based apps.
I guess specifically I would go to sun.com and look up concurrency mechanisms as this, along with
the BB specific inter-app communications issues, seems to be a big cause of confusing errors.
The other thing to remember is that the phone resources are limited and you need to be aware of how the JVM turns your code into resource usage.
[ after reading second page LOL ]
I'm not sure what your background is but I only used the IDE to copy command lines from the build window and write bash scripts for cygwin. Originally we wanted to build only midlets and this let's you do vendor independent code ( although the RIM devices are a lot more uniform and capable(?) than generic j2me phones and we eventually just went with those ) . The underlying RIM tools aren't that bad but there are little things like signature tool absolutely needs to popup a window even when run in automated mode. Automated builds for many versions are quite easy.
You also run into a lot of communications issues on real phones that don't show up on the simulators. The wireless environment is not reliable and I blame business interests for many issues.
I haven't used much of the RIM documentation myself as either their approach is familiar ( see sun.com and AWT tutorials if not just the j2me stuff) or I need to know about internal stuff that they have said they don't want
to document ( perfectly reasonable).
01-24-2009 11:48 AM
trope you left a couple off...
9. RIM killed Java's build once run anywhere motto by making it only run on windows.
10. you can't under emphasis how badly documented and the lack of good tutorials really hobble developers in wanting to keep writing for the BB platform, no point having a store if there are no apps for it.
11. lack of access to underlying hardware, lack of access to a lot of internal only APIs, in short hobbling the platform for either commercial or short sighted reasons. If people want to do something stupid.... let them, they bought the device let them do what they want to do on it, I'm referring here to using the camera flash as a flash light as a specific thing, it's not possible for any apps other than RIMs to turn it on.
I could go on, there is a lot of annoyances that have me eyeing off the G1 or another android platform as something I'd rather make apps for and since the OS code is available that should mean all the hardware is too. Hell even the phone with the dumbest name (the Pre) might be more developer friendly than RIM is being.
01-24-2009 01:04 PM
I'm actually not sure if this is RIM or the carriers responsible for most of this. RIM IIRC
makes most of its money selling hardware, the carriers want ARPU with low churn from customers who
don't use their network. Every app is another potential customer service call, most of which would go to
carriers, or an extra packet of RF carriers have to pay for. Of course, they have been defending their
walled garden and various stores against competition- as if a home made ring tone would kill them.
Since I grew up on microcontrollers and being an EE, I still like having complete hardware access and hate the JVM
but it does have useful features for this environment.
01-24-2009 02:41 PM
Since I grew up on microcontrollers and being an EE, I still like having complete hardware access and hate the JVM but it does have useful features for this environment.
Carriers are starting to get a clue about walled gardens being a complete and utter failure in terms of the customers don't care or want a limited selection when they're used to the internet and there is no way to put this genie back in its bottle, it's out and staying that way.
I wasn't asking for low level access to the device, just the same access as RIMs own apps, if a RIM app can do something, why can't a third party developer do it as well?
01-24-2009 03:09 PM
if a RIM app can do something, why can't a third party developer do it as well?
Totally agree with this. That's very bad when third-party applications are unable to utilize the same functionality as native apps do.
01-24-2009 03:13 PM
Personally I want low level access - people were asking about the imager and that would be fun
to play with as would the RF and other pieces. I haven't looked but most of these things, including
analog compoents are programmable ( probably things like digital PLL's etc) and could be fun.
If I got my US amateur radio license back, I'd be tempted to try to reprogram RF for an amateur
band as many people did converting Citizen Band 11 mete rigs into the nearby 10 meter amateur band.
Further, if they ever take my idea and put an electronic nose on a device,
and I noted someone makes a breathalyzer for iphone, I'd obviously like to play with that esp
if the nose is a monolithic chromatograph.
While we are on this, anyone used any bluetooth OBD-II modules? I'd also like to monitor my car's computer
on the road.
01-24-2009 03:52 PM
Some interesting points.I don't want to get off topic here.
You will all laugh, but I am jumping in head first and am going to develop this application:
I just need to master: