I'm trying to build a mobile application on a client-server model where clients are people's mobile devices and the server is a PC - all connecting over bluetooth.
I'm expecting the client to be very thin - just enough to establish communications, display some text, and relay user input.
What's the best framework to develop in? I want the maximum possible device compatibility (so for example not just series 60 capabale devices) as opposed to cool features - but the ability to scale easily to colour devices or ones with higher dispaly resolutions would be nice.
In the current mobile space, largest installed base + limited functionality = use JavaME. See http://java.sun.com and the the stackoverflow j2me and javame tags.
Easiest way might be to write MIDP application that uses Bluetooth API. That covers widest range of devices with least effort.
Related
I've made my app running on the Google Glass, but it's a little slow in real time. Is there a way to connect my Android phone with the Glass for data communication, so that the phone can take care of the calculation, and the Glass only show the result? The Glass can tether with Android phone by bluetooth, so it should be able to transmit data via it?
Don't know if it's possible to run my app on cloud server and send the result back to my Glass, but guessing that would be slow as well.
Any suggestion is more than welcome! thanks.
Yes, you can connect your Android phone with Glass for data communication, to receive internet content for example. This can be accomplished using Glass to WiFi (but you need the phone to set this up the first time), or Glass to phone to Bluetooth if your phone supports bluetooth tethering, which is often a carrier option.
If you are a Glass explorer this should have been explained when you picked up your Glass, but you can contact the Glass Guides for more information, if you are a Glass Explorer you will have this contact information. I have found them to be extremely helpful and fun to work with on usability questions. It doesn't hurt that if you visit them physically they ply you with treats and drinks.
If you are asking if you can open a socket directly between phone and Glass, that is not supported functionality, but you can request it. It might be possible when the GDK is made public, but there is no timeline for that.
If you wanted to do calculations on a phone and pass them to glass they would have to go through the cloud, as described here. Check out the section titled "How developers interact with Glass" and the accompanying graphic. I find it to be fast (sub one second with good connectivity), but that is subjective, your speed needs are not well defined in your question. A consideration is that every round trip of data will count against your API console daily limit, which is 1000 for most everyone. There is also a 10 request/second limitation.
Last note - there are unsupported ways of talking directly between Glass and a phone for a device you have direct access to, but this is not supported, and could not be used by other Glass users very easily. The techniques to accomplish this are alluded to in the Google I/O 2013 session: Voiding Your Warranty: Hacking Glass.
This forum isn't an appropriate one to discuss this, if you were to contact me directly somehow I could give you some pointers in the right direction, but I don't advise this route at all.
I am an Android developer. I haven't developed J2ME applications before. I have a requirement in which the client needs a J2ME application which requires me to store around 10,000 (Each record would have around 60-150 KB of data) records on the mobile phone. The mobile app will also be tied up with a backend server using a REST based web service.
The client wants the app to run on a specific mobile - Nokia 5233.
I need the correct options to proceed. Currently I am using the RMS and LWUIT. I chose them because:
RMS - I am using the CLDC profile. I am not aware of any DB that can be used with this configuration. Apache Derby is supported only in CDC.
LWUIT - There are many cases in the application where the TextField requires event listeners, the StringItem in LCDUI doesn't seem to have any event listeners.
Please enlighten me. I'm not sure whether I am taking the right direction.
RMS is probably your only decent option for on-device data persistence in J2ME (unless you go for direct file access using JSR-75, however if you aren't signed, the user will see all sorts of intrusive error popups when using this API). 10,000 records at 60KB per record, i.e. 614MB minimum? I've never heard of a MIDlet storing this size of data, RMS is intended really for a meg or two at most.
Why do you need to use J2ME? The 5233 is a Symbian^1 device, maybe try a native technology such as Qt? Probably far more reliable for that size of data, and easier to get a nice UI too.
(By the way, what events would you expect StringItem to give? It's a display-only widget.)
Most designers use 1024x768 as a baseline for website development. That allows them to use css grid systems like 960 & blueprint to easily outline content. Is there similar baseline resolution for designing for mobile phones?
The majority of users will be using iphone, android, and blackberry phones.
320 by 480 is the common screen resolution for new mobile devices.
iPhone Website Compatibility
Android Display Metrics
That being said if you want to support the majority of mobile devices, you may want to support multiple resolutions.
This website is super handy. An up-to-date database of various devices and their screen specs.
if you are using apache ApacheMobileFilter can help to determine the actual device screen size
You can
get the screen sizes for the devices you plan to support,
Create say, 2-3 versions of your site and detect useragent string and direct user to one of these sites.
With android, iphone and blackerry devices there is not large difference in a screen sizes. With a litle foresight and design you may be able to have all these handset work on one mobile website (for example it would be fair to say that the width would be 240 pixels or greater and design accordingly)
However if you plan to go further than there these platforms there is a world of hurt awaiting you, (J2ME, BREW, Symbian, WinMo and 120x160, 176x220 screen sizes etc)
I've found https://www.mydevice.io/#compare-devices to be the best site for determining this kind of thing. I was looking for the same and found this question via a Google Search, but most of the other websites mentioned above give you device pixels, not CSS/JS pixels, which is all that really matters in web development.
Sure, an iPhone 8 Plus may have 1080 actual pixels across its narrowest axis, but that is completely irrelevant to the topic at hand, considering that those pixels are much, much smaller than your HD TV for example. I wanted to measure the width of the display in relation to how a browser actually renders a mobile site and mydevice.io gives you that, as well as the physical dimensions. Win win! ;-)
Simply, no.
Lots of information here. http://www.quirksmode.org/mobile/
There are just too many devices with too many different screens to assume a common resolution. While it may be true that 320 x 480 can be found on many devices, it is by no means "common". You have to use flexible design principles and then use media queries or js detection to add a class to adjust your display to the proper dimensions. This is part of what makes mobile so difficult to wrangle right now.
yes there are 1024 x 960 x 800 x 768 x 640 x 480 x 360 for resposive web design sizes - better to go with percentages for avod this
I write games for mobile devices. In my code I position everything by percentage as it will always be the same, plus I also use a var to adjust how many pixels they have then set my resolution to suit You can do pretty much the same with css and a few different image size's in your resources.
I want to be able to track a person through their mobile phone and
display those whereabouts on a website. I read some stuff here about Safari and iPhone.
What I need is a starting point in the sense of what is possible, and
if it is only possible for certain phones. I can ask a lot of specific questions as I've read bits and pieces everywhere, but what I need is a general layout of what needs to be done and, if possible some of the steps to accomplish it.
Thanks.
Well, if we assume you are starting from scratch, here is a high level list of things to figure out:
familiarise yourself with geolocation coordinates and the gps system. If you need to make sense of the raw location data, there is some math involved.
pick a location-aware mobile platform. Some phones will implement jsr-179, which is a JavaME API. In addition, you can get location data using python or C++ on Symbian phones. I suspect Android and iPhone both have their own location API.
figure out application deployment for the platform you picked. How does the mobile application get on the device? A phone manufacturer or network operator application store, a third party store like www.getjar.com, pre-installed on the phone via a partnership with the manufacturer or the network operator...plenty of options.
come up with a sensible way of packaging mobile location data and send it over the network to a remote server.
make a website to display the location data stored on the server.
Speaking entirely in technology-free terms, what is the best way to make a mobile friendly site? That is, I want to make a site that will work on a regular computer but also have mobile versions of the pages. Should I rewrite each page? The pages will probably have different functionality, so should I rewrite the backend code? Should it be an effectively different site with the same database?
On my site, I detect user agent, and for known mobile browsers I serve a different stylesheet, with some larger/less necessary items left off some pages. The backend doesn't really change.
I added a mobile presentation layer to an operational site about a year ago. Based on the architecture of the site (hopefully this isn't too technology dependent for you) I added a new set of JSPs to accommodate mobile browsers (sidenote: see http://wurfl.sourceforge.net/ for a great way to build mobile pages independent of browser type). Additionally some of the back-end functionality was changed due to the limited functionality of most mobile browsers. So, in short, the integration wasn't as painful as one would expect.
Good luck!
This is a pretty broad question, but here goes:
If the site is primarily about the content, meaning it's not so much a service you use as it's a publication you read, then I'd try to avoid publishing two sites wherever possible. Concentrate on simple presentation using mature technologies that mobile browsers can handle fairly well.
If it's essentially a software application delivered via the network, then things get trickier, because you're going to want to consider the UI of the mobile device, and how it differs from the desktop.
This should go without saying, but either way, if you have many mobile users, you should keep that in mind when you author content for the site. Formats, length, voice, etc.
In addition to the WURFL / WALL capabilities system that todd mentioned, there are Java Server Faces libraries available that use alternate WML renderkits for mobile phones.
One way I have done it in the past was to make sure my data was abstracted well in the data tier and then use separate middle tier models to pull what was appropriate. In my case the application was a weather application and the display methods of the target devices were really limited so we opted to only show the user the essentials on the mobile devices while the website was full featured. That was probably 10 years ago when WAP was big. But these days with devices getting bigger screens, better bandwidth, you may want to consume and display the exact same data with a different view model.
I never really know what type of application will need to consume the data in the future. We do a lot of apps across platforms but the domain model rarely changes. So I end up using the same middle tier objects where I can and pulling that data in different clients. A good example of this is a recent project where we had a rich internet application (widget), a full website, and a web service consuming the same data. Data abstraction in the middle-tier really shines in this environment.
On a very high level of abstraction, there are two main caveats with mobile devices: (1) their screen is small, (2) their network connection is intermittent. This basically means that your need to present the content so that it looks fine even on a small (variable size) screen, and preferably make it cacheable too so that your users can browse the content while offline. Then there's also the problem of low bandwidth and high latency, but those are slightly less important nowadays.
This is a very thorough overview of how to make a site mobile, though i hope its fair to say that there will always be different requirements for anyone seeking to go mobile. If you have a Blog, then you could just as easily make it mobile friendly using Mippin Mobilizer; its free, provides branding customisation tools, and with a big audience already browsing a wide mix of mobilized content, there's opportunities to generate advertising revenue around your blog.
This is because the Mippin Mobilized blog then becomes part of a much wider community of content, people, news, blogs, listings, all connecting around content, and much more at the mobile site:
http://mippin.com (on a mobile browser.)
Take a look at the Mobilizing tool because it shows off what the site can do in a second:
www.mippin.com/mobilizer
Only if you have a blog of course...