 |
|
|
We use tablets with 3G out in the field under XP.
This survey could concentrate on the issues of mobility such as occasionally connected, db synchronisation etc not the phone OS
|
|
|
|
|
|
|
Yeah, these surveys are never well thought out.
|
|
|
|
|
|
|
I do mobile development with Windows Mobile and Windows CE on hand held devices. Phone development is slightly different.
And I agree with the last statement.
|
|
|
|
|
|
|
|
|
|
CD's and DVD's fly just like frisbies. 
|
|
|
|
|
|
|
Laptop computers don't fly that high, but the apps can even run wireless...
This statement is false.
|
|
|
|
|
|
|
...developing for the iPhone. But, I got a Windows Mobile app coming up through work. Still a nice change of pace though.
|
|
|
|
|
|
|
When mobiles have a much faster multiple core processor, 4GB of memory, 100 or so GB of storage, a 100 MBit internet connection, high resolution display, and have a rich native (no .java or .net) API I could see this happening for my medical imaging applications. I mean bringing patient exams at full resolution to the doctors hand held device.
John
|
|
|
|
|
|
|
This just means that for old-timers like myself, who have experienced programming in 4K of memory, we'll be ahead of the curve of you young whipper snappers 
|
|
|
|
|
|
|
Yes, I used to program on punch cards while walking to school, barefoot, and uphill both ways.
But seriously, it is sad that none of the new coders I am interviewing would know how to parse a binary file, or even use a simple low level API. Very few could even tell me what a pointer actually is and why it is used.
|
|
|
|
|
|
|
I programmed on my vic 20 in the early 80s.
Anyways the data for a single case that I need to visualize can be over 500MB. At times this can be hard on a modern machine. I mean if you let 3D visualization libraries make more than 1 or 2 copies your fragmented 32 bit address space gets exhausted. Visulization is fine at 64 bits software wise but then that requires all your clients to upgrade and they do not want to do this and in a lot of cases they can not because the medical hardware does not have a 64 bit driver.
John
|
|
|
|
|
|
|
the .netcf isn't that bad, but the process of designing system is much different then a full OS. I build industrual control applications and they seam to work fine on the small platforms, but i've found that resources, arrays, threads, and loops need to be carefully watched over, you can stop a system cold if too much is done. For most when building an app in full windows we never see the full impact of the choices we make because the systems can make up/clean up the mess rather quickly.
I'm not implying that your medical apps don't need the horsepower or that that anything is inefficant there. I've just meet alot of nay-sayers out there who say it can't be done (even in my own company) and 9 times out of 10 it can, you just need to think a little different.
I personally like the challenges that come with making a limited resource, single use device, it's a good change from dynamic do everything control systems that we normally do.
check out these small computershttp://cubloc.com/product/05_01.php[^]
|
|
|
|
|
|
|
John M. Drescher wrote: I mean bringing patient exams at full resolution to the doctors hand held device.
"Full resolution" on a 5" display? What am I missing?
Gary
|
|
|
|
|
|
|
ghle wrote: "Full resolution" on a 5" display? What am I missing?
I think it's something about the famous sub-pixel rendering in WPF. [^]
Greetings - Jacek Gajek
|
|
|
|
|
|
|
Jacek Gajek wrote: I think it's something about the famous sub-pixel rendering in WPF.
Doctor - "See that? I know it's rather fuzzy, but that's a tumor in your head."
Patient - "Doctor, isn't that just my eye-ball?"
Gary
|
|
|
|
|
|
|
This question would have the same answer if it were
"Are you planning to develop for a specific OS?"
NO!
Web clients are getting richer, so web app are able to fit more and more business areas where the complexity once made web choices unproductive.
So, why bother with the client OS?
I already have to bother about the client browser, so being a mobile browser is just one more concern... maybe a few custom pages to show less data but no OS specific development anymore.
Cheers!
Alex
|
|
|
|
|
|
|
AlexCode wrote: So, why bother with the client OS?
- Because the web isn't as responsive and rich. Try making use of the accelerometer from a web page.
- Because not everyone has uber amounts of data plans.
- To interface with hardware.
- To run in a disconnected state.
- Kiosk applications.
And I'm sure there are more I can't think of off the top of my head. And I'm very pro web, but saying there is zero reason for a client app is silly.
|
|
|
|
|
|
|
|
|
|
Jeremy Falcon wrote: I'm very pro web, but saying there is zero reason for a client app is silly.
I completely agree. I'm a full time, client developer. I know lots of reasons to build client apps.
|
|
|
|
|
|
|
Jeremy Falcon wrote: To interface with hardware.
Inroads being made on this. Palm webOS has access to various hardware bits. iPhone 3.0 mobile Safari has access to GPS. I'd except most hardware features to be accessible in the mobile browser in the coming year or two.
Jeremy Falcon wrote: To run in a disconnected state.
iPhone does this (HTML5) and Palm webOS does too.
Jeremy Falcon wrote: Because not everyone has uber amounts of data plans.
Yeah, still a problem though at least over here most smartphones are being sold on contract with 3G data-plans. I never hit my monthly 1gig cap.
|
|
|
|
|
|
|
Oh, I know things will merge and get better in the future, but as for now it's not universal these things you mention and if you want an app out today it's not feasible to just make a blanket statement to say client apps are pointless.
|
|
|
|
|
|
|
|
|
|
Sure not everything is doable on web but most things are, and I can tell you that:
-> the biggest advantage for developers is the ability to have all the clients with the latest software version without any effort
-> the biggest advantage for customers is to have their data centralized.
Sure the web client is poor, sure it may be slower, but again... who cares?!
Certainly not the customers!
You give them a fully working solution and they don't care if it's web, windows, Linux, SQL Server, SQLite or whatever technology you use...
Make it useful, practical and time saving that they want it :p
Cheers,
Alex
|
|
|
|
|
|
|
AlexCode wrote: Sure not everything is doable on web but most things are, and I can tell you that:
I'm fully aware of the pros and cons, and I do consider myself an expert in this field I can tell you that. That being said, I was counter-acting your blanket statement which was just plain wrong. This does not mean I don't understand the benefits of the web.
AlexCode wrote: -> the biggest advantage for developers is the ability to have all the clients with the latest software version without any effort
-> the biggest advantage for customers is to have their data centralized
This both true and untrue. Updates/minor updates and centralized data can happen with a client app. The *biggest* advantage of the web is a thin client architecture so you can have major updates be transparent and skip an install. Everything else you can do with client apps, including go multi-platform.
AlexCode wrote: Sure the web client is poor, sure it may be slower, but again... who cares?!
Certainly not the customers!
I'd wager you don't much experience in customer relations if you think they don't care about the experience. In fact, that's all they care about because they don't see the code behind it. Presentation is everything. And yes, the web can do a lot for a lot of cases and is very nice. But, client apps can do a lot as well.
AlexCode wrote: You give them a fully working solution and they don't care if it's web, windows, Linux, SQL Server, SQLite or whatever technology you use...
They'll never care regardless of client or web. They're not techs with preferences. They just run the install and click buttons. They're users after all. And you can still do multi-platform on the client.
AlexCode wrote: Make it useful, practical and time saving that they want it :p
Oh yeah because it's obvious a client app can't be useful or practical. Thanks for clearing that up. 
|
|
|
|
|
|
|
Can't run a manufacturing system on the web, and why the hell would you.
|
|
|
|
|
Suggest a survey
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin