Is there any Page which collects all Data about Future / Past Releases or Updates to Mobile Operating Systems ?
If not, do exist a Page for specific OS's ?
I'm sure if you go to the Operating Systems website they'll have things like recent changes and changelogs.
I don't know of one place that has it for all of them. for popular mobile systems i check news websites like androidcentral.com or crackberry.com, there are links of both these sites for new on android, blackberry, iphone, nokia and windows phone. they often do reviews and reports on new os releases and discuss the changes that have been made.
But for a deeper look i would check the website for that operating system, thats were you'll find the information needed.
Not exactly what you're looking for, perhaps, but this is something that might be of partial relevance
http://upload.wikimedia.org/wikipedia/en/f/f7/Mobile_os.png
http://en.wikipedia.org/wiki/Mobile_operating_system#Mobile_OS_comparison
Related
In a os x app, which is the best way to store hundreds of user record with a lot of information for each record?
I know that i can use CoreData, SQLite, Realm, plist or other solution.
Which is the most compatible (i think for example for a web use) and clean/light/fast method/type of database to store data ?
thank
Core Data is written by Apple to be used in Cocoa based applications. It is already included on the operating system, has 10 years of development behind it and is used in hundreds of thousands of applications on the app store already.
Using a third party library has tremendous risks associated with it.
I always recommend using Core Data on iOS and OS X because it is written by Apple, has a fully supported team of developers behind it and is a mature code base.
Using raw SQLite is possible but you will not get the same performance benefits as you will with Core Data.
Realm is focusing on the wrong things. Their data migration system is scary, they focus on raw speed when they need to be focusing on the overall picture. They might be targeting mobile but I do not agree with their goals.
Hundreds of records is not hard for any database system. It is when you get to 10s of thousands of records on a device that many of them start to fall down due to memory pressure (even on OS X).
Core Data is designed to help with the memory pressure. I am not aware of any third part framework that will do so.
I think the most important thing is to compare Realm with the other database. Realm use its own core and the others are based on SQLite (CoreData use SQLite).
Realm is the first database designed for mobile use. So with your case (OSX) you must consider if your app have the same functionning as mobile App: device restrictions.
Realm:
Very fast methods: see example here
Rapid execution: see benchmark here, yes thousands of user records!
Light: the embeded database less than 1MB
But in beta state. This mean that they are constantlyy in development
SQLite:
the "lite" in the name mean it's a light database. You have many libraries available in github to help you, full documentation and full examples.
Personnaly, I use Realm for My OSX App and despite it being in a beta state, I have all the features I need. Realm is faster than CoreData and save me thousand of lines of code and months of work. :)
I hope that this will help you.
If I want to implement CMS for Mobile Devices, what kind of points should take into account?
For example, make page size smaller, use optimized (small) pictures. Any other ideas?
Also what kind of rules can be applied while converting web-pages that WERE designed for Desktop Browsers, to the ones that are easily displayed in Mobile Browsers.
I know that Mobile Devices widely vary in there capacity and property, but still trying list out some rules.
Also any other ideas, suggestions, questions and advices are welcome on this topic.
Thanks for your opinions and answers.
Short foreword, all the things I'm listing below are something the main product of the company I work for already does or has worked out a solution for, the whole goal of this answer is to give you pointers.
Identifying the phone
When dealing with mobile as a web context, it's absolutely imperative you identify the phone correctly. That should be the highest priority. Here's couple of issues with identifying phones and their features:
Do not use userAgent.contains("iPhone") detection scheme. There's already loads of web bots and other applications which contain iPhone in their user agent string and thus you'd identify them incorrectly.
Not all phones even send User-Agent headers. However some of those send UAProf URL:s which contain all the phone's features in RDF format. Unfortunately this introduces the next two problems:
Obviously you won't have access to every single device data out there and you're bound to use public data repositories such as WURFL. These databases are however incomplete, slightly lagging behind or don't contain data you'd like to have. They are your best bet for initial data set though.
UAProfs lie. Yes, they contain false information - lots of it! Partly this is because the manufacturers forget to update the XML:s and partly because the UAProf files are written during the development of the phone and as we know, features do change during development.
When relying on a feature, make sure you're not relying on a specific version of a specific phone. For example BlackBerry has a feature called Tile which is basically a really fancy bookmark but you can't just serve it to all the BlackBerry phones, you have to identify the operating system version of the actual phone to serve the right variation of the Tile. Same goes for touch screen, iPhone wasn't the first one with touch screen and most certainly isn't the only one either - also don't expect a situation where the device has only one form of input, for example Nokia N900 has a touch screen, physical keyboard and even stylus.
Creating the actual pages
Thankfully this is something people have agreed upon and when creating the pages, you're supposed to use XHTML-MP. But oh how one would wish things were this easy...
All phones have differing level of XHTML-MP/CSS support. As an example, if I remember correctly, some older BlackBerries don't support background-color for block elements. Or header tags. We've also seen incorrect ordering of span elements when there's several in a row. Oh and for some reason tables are really hard. Basically, you have to go low on markup/styling tricks.
You can't test the existence of the feature by using the feature itself. If you want to detect JavaScript support, you could think that adding a bit of JavaScript to the page for that purpose alone would work, right? Nope, that crashes a significant percent of mobile phones visiting your site. Sure, new phones don't crash but not everyone has bought their phones in the last 12 months. Also mobile specific JavaScript API:s differ per manufacturer, as yet another example there's currently at least three different API:s for JavaScript-based geolocation detection, none of them interoperable with the other ones.
Add all these on top of normal CMS features (security, content management and transformation, caching, modularity, visitor tracking and whatnot) and you should have some sort of picture of how everything affects everything and how you really should consider the cost of making your own.
In fact even though this is sort of against the general spirit of SO, I'd strongly suggest for you to get a readily made solution such as ours and use that instead for your site building needs. After all, our product has seven years worth of specialized development under its hood.
A couple that we used ...
A cms targeted for mobile devices should be able to detect the device type and detect (or have a database of) screen resolutions so that content, particularly images, can be scaled appropriately.
The rendering engine should also be able to determine if the device can handle HTML or WAP and switch markup languages appropriately.
Paging capability on the output as opposed to rendering very large pages (if content mages are large) is also helpful.
Clean integration with the corresponding web site CMS (so content doesn't need to be dual produced) is also helpful if tere is, in fact, a corresponding large form web site.
I'm not a Silverlight developer (yet) and what is putting me off - and many others, I think - is the relative lack of browser installations of it compared to Flash.
But I'm not clear on why website visitors have to explicitly install Silverlight themselves - which appears to be the major stumbling block.
Since the vast majority of computer users use Windows, is there a reason that Microsoft are not forcing Silverlight onto Windows machines through a Windows update?
They do this (and continue to do so) with the .NET framework runtimes, so why not with Silverlight? Legal issue, perhaps?
Getting sued by all its competitors is what stops this
There are several reasons why not to do it.
Users should have choice over what gets installed. I realize from a developer standpoint we know some users who are clueless about what this software does, so why put the choice in their hands? Fine, MS should make it easy for users to install it if they don't have it when they visit a site that uses it. Then they can make an informed decision. Do I want to use this site or not?
Corporate Approvals. Companies go through software validation procedures and that is why some will still be on XP for some time. If they were forced to validate these pieces because microsoft was forcing them down the pipe, they'd be pissed off. So thus MS gives corporations control over the windows updates that get approved/installed. And corporations are where MS makes their money.
PC Manufactures choosing what software to preinstall. Here the manufacturers have the ability to push silverlight or not.
Competitor's software isn't automatically installed. You actually have to install flash. Some PC manufacturers might bundle it with the PC but if you install yourself or for a corporate deployment, it isn't there by default.
The monopoly power abuse concerns mentioned. But I think this is actually the least important reason.
Silverlight won't hit mainstream adoption till there is that one app that everyone must have that uses it. Like the office online example above.
I think that would be the wrong way to go about trying to gain adoption. The product should merit installation on it's own, not lean on the Windows installation base for support. Writing the free version of Office online (EDIT: I meant the Office Web Applications) in Silverlight, however, is a great way to gain adoption (even with the non-SL version available too http://blogs.msdn.com/officewebapps/archive/2009/08/05/9858563.aspx).
Also, since this is a browser plugin, how would that work? Can a Windows update install plugins for firefox, opera, or whatever browser the user prefers? Doesn't seem feasible to me but I'm really not sure.
They actually suggest it in Windows Update. I politely refuse it.
There may be an anti-trust reason for this also, remember what happened with Java, even when it was from Sun they still had a problem with it.
If you keep waiting for Silverlight to catch on, it never will be enough, start developing now and when there are many great web-apps that support Silverlight then maybe it will get more popular, plus it is very easy to install and you can target Mac and Windows, and some extent Moonlight too as it reaches support for Silverlight 2.0 and some 3.0 there may be Mac-Windows-Linux apps you can write.
I recommend Silverlight to anyone who develops in .NET, I am a little biased as I'm writing an application at the moment in Silverlight.
I suspect that they are waiting for the technology to mature and/or gain more acceptance. Once a critical mass of sites and/or users have it installed they might do.
The other alternative is that they might be waiting until they've completed the "merger" of WPF and Silverlight. I can't see them continuing to keep these two very similar technologies separate.
After all Adobe don't force Flash on everybody.
Can't speak for Microsoft, but I am dismayed by the question. I don't want extra crap pushed to my machine (or into my life in general). I only want extra stuff if I pull it. Stuff like that should always be "opt in" instead of "opt out" or "no option at all."
The european union has filed anti-trust suits against Microsoft which is probably why they don't put it in their updates.
I however don't install it because i don't like unnecessary processor cycles being used up for advertising much in the way that flash is used. Flash I've uninstalled on many of my computers in protest, though i admit it's on my media center in the living room because people use it for you tube.
For all the hype, Silverlight is not all that great to develop in and doesn't bring anything to the user experience that couldn't be better achieved through dhtml/ajax.
I've just discovered J2ME and I love the possibilities that it presents. I'm currently working on a simple application and I'd like to maybe release it as an open-source project sometime in the future.
As part of my research into J2ME and mobile devices, I looked into applet signing. It seems that people who want to create applets for free are caught between and rock and an awful shite-place. Applet signing is extremely expensive and extremely convoluted - and the expense can't be justified when coding for free.
There are a huge number of J2ME compatible devices out there - I think it would be a shame to have to ignore them, and just wait patiently for the next wave (e.g. Android).
I was wondering if other people have any ideas about ways to approach this problem?
UPDATE: I found this blog article which summarises the problem for those interested... http://javablog.co.uk/2007/08/09/how-midlet-signing-is-killing-j2me/
I thought about setting up a non-profit umbrella organisation for open-source J2ME developers who want a VeriSign certificate (as a certificate can sign code an unlimited amount of times). I would aim to raise the $500 and then enable group members to share the purchased certificate. Had a quick chat to a VeriSign rep and they thought the idea could work (as long as the organisation was registered as a legal entity).
However, since handset manufacturers now seem to be moving to support only UTI root certificates (which you can only get through the 'Java verified' programme) - this might not be as useful as I thought it could be... if anyone has any ideas would be great to hear them.
I am afraid that you are fighting a battle that you can't win. Using the restricted APIs is getting harder and harder and this is not accidental. As you've read in the blog entry you've mentioned the biggest problem is the network operators. Even if you buy a certificate from Verisign or Thawte (which is by the way cheaper), your application won't run in network operators branded phones, since these have their own CA rules.
At first it was possible for a developer to install his/her own certificate, but even this is now not possible. This strict rule is mandated by the phone manufacturers (Nokia for example) and applies to all phones (even no branded ones). I believe that this too is not accidental and is mainly because of pressure put to device manufacturers by the network operators.
Finally, although MIDP 3.0 has been announced for years, nothing has really come out of it. It seems that even Sun believe that J2ME is only for games.
All of these have been extensively discussed in J2ME forums for a long time. The general consensus is that the network operators do not want to have every phone available in the market operate as a smart phone and be able to run a third-party application. Then it will be very easy for everyone to use a cheaper, web-based alternative instead of SMS messaging for a example. This may sound as a conspiracy theory, if you are new in the J2ME world, but have in mind that network operators sell phones with their own firmware that lock even basic functionalities (e.g. transferring photos via Bluetooth or using MP3s as ringtones) to force the owner to use paid services!
I don't know if this is going to change now that smart phones (iPhone, Android, Windows Mobile) are gaining momentum. Have in mind that restrictions apply also for these platforms (notably Symbian, which is also very unfriendly for open source).
You can create a signing certificate
that you self-sign. Your users have
to be willing to trust you.
You can instruct your users how to
create a cert and self-sign with it.
Then the users have to be able to
trust themselves.
There are more or less open CAs; you
have to be willing to trust them and
convince your users to trust them.
The Java Tutorial has a section on signed applets that will lead you through the steps.
I'm a J2ME application developer and i totally agree your post. The costs for signing a MIDlet are simply unaffordable for open source initiatives and unless your're developing simple games, you'll soon or later end up in using restricted APIs to access sockets or Location API just to name two of them. This is very frustrating and if you consider that the permission policies are not always threated the same on various devices, the thing get worst: on some mobile phone you can tell the OS to trust the entyre MIDlet and never bother you at all, other continue to ask you permission every time you call for a restricted method. It's tragic!
I rellay appreciate your proposal and i think it would be a great achievement for JavaME developers.
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...