What is the purpose of the rendering application class in Blackberry?
First, it is an Interface(#see http://www.blackberry.com/developers/docs/5.0.0api/net/rim/device/api/browser/field/RenderingApplication.html), it can allow you to implement HTML rendering in a variety of applications (#see http://www.blackberry.com/developers/docs/5.0.0api/net/rim/device/api/browser/field/BrowserContent.html)
I personally have used it to render RSS HTML content for display in a typical Field among other things.
It allows you to implement callback functionality to gather resources from the HTML (images, etc) and render them appropriately (if you desire).
This of course is the 5.0 and under version, as I have not been privileged to have a 6.0 user base so I cannot comment past 5.0 :)
edit: Oh yeah, it also allows you to handle HTTP events (redirects, etc)
Related
I am trying to create simple app but it will give me headache to implement simple plugin like tabbar so i have created it using simple HTML.
So my question is if i create my app using simple HTML not even using HTML5 than does it make any difference? Does apple approve it?
No. It shouldn't matter.
HTML5 adds more features to HTML. So any browser which can render HTML5 can render HTML too. But why don't you use HTML5 new features. Anyway, if you stick into HTML. You misses out the ability to use any HTML5 based libraries.
I am going to create a mobile site(using Sencha touch) for an existing website. The functionalities are coded already using Ruby on Rails. If I go with adding mobile site to existing one it will make me to add conditional rendering based on the request headers or else go with creating a separate app on m.mydomain.com. I am a bit confused. Please guide me to make a decision.
I would recommend creating conditional rendering inside the existing application, primarily because you will have access to the models and utility classes within that application.
If that's a significant problem for you, you could separate out the two codebases and have the mobile site be an engine of the application, so you would still have access to the main application's classes.
I would go with m.mydomain.com and redirect the user to this automatically based on their device. T
he good thing about this is that you can have a link at the bottom of the page that is "View full website" in case the mobile site isn't what the user wants.
This also makes it easy to have separate views for the mobile site, keeping them cleaner.
I recently made a sample app that you can view on github that does something very similar. The only difference is that I am not detecting the device, I have the user visit the appropriate URL. I also used jquery mobile, but the concepts are very similar. https://github.com/jfriedlaender/mobile_blog
I have been developing a simple app using HTML pages that are interlinked. They will be using some form of data persistence. I have not decided yet. They will be displayed on an iPad in both landscape and portrait modes.
I could wrap them in a UIWebView and roll my own app that way, but to me it seems that others must have come across this requirement before and there might be a simple framework to do this.
I don't need any special access to location data, accelerometers etc. Just plain HTML, some CSS and Javascript. The most complex of which will need to store a series of name value pairs (circa. 150 items) that will need to be available to all pages within the application. I have no need to call the Javascript from the app or vis versa.
I will need to insert inApp purchasing in future to the application, whereby I will load a larger set of HTML files. It might be nice to be able to trigger that from inside the HTML pages but that is not necessarily a deal breaker.
There are a number of frameworks for writing apps in HTML5 etc. and converting. I don't really need this either.
But I would rather use some framework that will take the lessons learned by others and let me deploy my app on an iPad with minimal risk.
Can anyone give me advice regarding the best framework for this use case?
Thanking you in advance,
Andrew
I would use phonegap. It works on the iPad no problem.
You can use the camera and accelerometer and all that with phonegap-plugins.
I am using it on a few iPad projects, and since you can use HTML/CSS/JavaScript, you can pretty much just configure phonegap with your web address and your web app is now an iPad app (that or just add static html files to the phonegap project directory). Then it's just 'modify the design and layout HTML/CSS'.
I am working on a Rails app that declares a :mobile format for iPhone and Android and serves up show.mobile.haml for mobile and show.html.haml for web (for example).
The mobile request format obviously uses application.mobile.haml and web uses application.html.haml - but both layouts are the same, only the views differ.
My question is - how do I use a single application layout for both the mobile and html request formats? Have dug through the Rails API documentation and can't seem to find an obvious solution.
You don't need to do anything. This happens automaticly when you add an extension to your urls. If you go to /controller/action.mobile the action.mobile.haml view will be rendered. If you go to /controller/action.html the action.html.haml view will be rendered.
This behaviour is managed by the format parameter (you can see this in your routes file). So /controller/action.mobile is the same as /controller/action?format=mobile.
Ofcourse, sometimes you'll want your actions to behave differently depending of the current format. This is supported be using the respond_to and respond_with method. More info about these can be found here.
Is there a templating language that has both server-side ruby (pref. rails) and JS renderer?
Here is why this would be useful: Consider you want to display a big list of songs. You render the first 50 and a "show more" button.
"Show more" would link to the next 50 songs or would load those with AJAX if JavaScript is enabled.
The simple solution is to return a rendered piece of HTML from the server, but consider how nice would it be songs were returned as JSON and then were rendered using the same template on the client side.
Mustache.
It is Ruby based but there are several different implementations, including JS.
hamlc supports both sides...
slim has a client side version too it is called skim.
Node.js offers the appeal of using javascript on both the server and client side. If you are looking for something more ruby-on-rails like, then check out express.js which is a web-framework built on Node.js. Both of these are server-side frameworks but they offer libraries which can be used on the client side.
Something to keep in mind is that if you are rendering views from JSON data on the client side then you will need to have the client load the javascript libraries to perform these operations and then render the views - which may be a costlier operation. That said, if your view is simple enough, you can always write a simple javascript function of your own to render your JSON data rather than relying on an entirely new framework and view renderer.