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
Related
I'm building a reading application and want to try using phoneGap for the first time. I'm comfortable with HTML, CSS and JS, but don't have much experience with xCode. Let's say that for this reading application on the home screen I have a button. When the user clicks the button I would like it to redirect to another screen/view. Would the correct way of doing this be just to create a link on the home page and when they click it redirect them to another view? I don't think I would need another model or controller, but I'm not certain.
The best way to implement multiple 'views' in a Phonegap application is to use the 'single page application' design pattern.
Phonegap applications are native applications that set a native webview as the default and ONLY native view for the application. Though you can use plugins to implement other types of native views, a basic Phonegap application only uses one native view.
You are able to program with HTML/CSS/JS within the webview anyway you prefer.
If you are not familiar with the single page website design pattern here is a basic explanation:
One single html file
Use div containers with specific ids to show and hide content
Ajax requests are used to manipulate data within the application (so no page refreshes are needed)
I'm working on application with some sort of CMS features. I need some pages to be editable. For instance:
you can edit a text block right in your browser
you can add and remove different modules to your page
For instance, if I have a main page I may want to edit welcome text.
If I have a sidebar I may want to add/remove new modules to the sidebar such as:
email subscription module
social network (facebook, twitter, etc) links block
text block
My application may have several pages, not only one.
I want to keep it simple and I'm looking for the right approach/examples/existing tools.
What's the best pattern / third-party solution for ASP .NET in order to implement this and keep it simple?
If you want to use ASP.NET MVC I think the best solution is to look into Orchard. It's really easy to get up and running, has a rich set of existing modules and building a module from scratch is really easy. This was actually started by a couple of Microsoft guys and then spun out into it's own open source project. http://www.orchardproject.net/
I have a site that's done using ASP.NET MVC and jQuery. Is it possible to modify my existing project without too much of rework so that it can be used in phonegap to create iphone/android apps?
Here's an approach: move your logic to an MVC WebAPI (or other REST/webservice) project, then convert the MVC site into a simple html/javascript/css/image site (Mobile site). Then refactor your Mobile site to use Ajax/JS to query the WebAPI/Rest services you created. Once you've separated your code this way, you can then package the Mobile site with Phonegap. I'm not sure how much work that will be for you or your project. If you're using a lot of Html Helpers or Razor markup in your views it may be too involved.
The core point of my suggestion here is to separate your mobile UI layer and the backend processing layer so you can only package the Html5/UI/Javascript layer with Phonegap and leave the backend processing on your web server. I don't think I need to explain this, but obviously the app packaged with Phonegap is not going to have the MVC/.Net framework available on the mobile device to render views or execute controllers, etc. By migrating your UI to be simple Html5 and Javascript you can use Ajax/Jquery/Javascript calls against your backend, which you will probably want to host in ASP.Net MVC WebAPI.
Edit: Guess there was some confusion about my suggestion. I'm not saying this is the only way to do go, but this is what I'm familiar with as it's how our team builds our desktop/web + mobile + phonegap + mvc4 + webapi + kendoui application. This pattern works well for us so maybe it'll work for you too, or at least give you some ideas on how to structure your solution. Good luck!
I'm not sure but you need a server to compile the ASP.NET right? so I don't think that will work for you. I think you need to work with AJAX to do your ASP.NET work and separate your ASP.NET code and your HTML-jQuery because Phonegap wants a index.html file. You can store your ASP.NET files at a server tough
The answer to your question really depends on the type of site you are trying to convert. Are you just trying to put a native framework around HTML and get your app into an app store?
If it is is mostly or entirely informational in nature and you have simply used MVC to build brochure-ware type pages then it should be fairly easy to move. This assumes that there is little to no logic other than page to page navigation.
If your site instead pushes a lot of data around that relies on a back-end server you will need to re-architect it to store data locally or pre-fetch it via a manifest. Next you will need to implement a strategy that allows you to push your local data back to the server.
Does you app need to run in a disconnected state?
Phonegap is one of the options if you want to target multiple mobile platforms & may be most widely used. Since you are using jQuery, jQueryMobile will be a least learning-curve path to use. Effort is mostly on the front-end UI and will depend on how many screens you want to design to provide a sub-set or the full set of functionality you already have on the web UI. Most likely you will have to redesign your screens using the jquery-mobile UI widgets documented here. It is also a good way to show it to your customer the initial screen design with navigation.
jquery mobile is great for learning and designing , but it's slow in the web browser control that phone gap runs in .
you'll need a more lightweight framework for this .
you can use an inappbrowser control to show your site in case it's responsive , but you wont have the device camera and contacts and so ...
take a look at : http://docs.phonegap.com/en/3.0.0/cordova_inappbrowser_inappbrowser.md.html#InAppBrowser
This post has been 'somewhat' addressed (see links at bottom of post) but not to it's full extent.
I am working on building a mobile site in Rails 2.3 (I know, I'm going to migrate to Rails 3 soon). Either way, as I continue developing this mobile site (and I am using Mobile Fu - works great), I'd like to understand best practices around configuring and managing the mobile site:
Where should I redirect to the mobile domain (in application controller)? What is the best logic for doing this?
Should I build the .mobile.erb files in the same folder as the .html.erb files? Or in a separate mobile folder?
What kind of routes/controller/etc logic do I need for my mobile site (if I decide to not embed the mobile rendering inside my current application structure, but instead have a separate controller and mobile view folder)?
I appreciate it.
Other links:
Web and Mobile views best practices same controller or namespace?
http://www.arctickiwi.com/blog/mobile-enable-your-ruby-on-rails-site-for-small-screens
Rather than answer your question directly, I am going to suggest that best practices have moved on somewhat.
Concepts like Mobile First, Adaptive Design, Responsive Design, and Progressive Enhancement are replacing the split site approach as best-practice.
These concepts revolve around building out your site for mobile first (so you can work out what the most important things are) and then extending the design for screens that are larger.
It removes the need to determine if it is a 'mobile' accessing the site and instead relies on various techniques (adapt.js or CSS media queries) to target different layouts to the variou screen sizes. It also means you do not have to maintain multiple views and routing - you have one view and change the CSS.
When you move to Rails 3.1 (with the pipeline) this allows the creation of CSS (and JS) manifests, and you can (potentially) have one manifest for each screen size.
There are issues with the above approach (just as there are with split sites), but if you Google the key terms above you'll find tons of advice. Best of luck either way!
Edit: Here are some links I found useful.
http://www.lukew.com/ff/entry.asp?933
http://www.netmagazine.com/features/mobile-first
http://www.alistapart.com/articles/responsive-web-design/
http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/
http://www.alistapart.com/articles/taking-advantage-of-html5-and-css3-with-modernizr/
http://www.sitepoint.com/regressive-enhancement-with-modernizr-and-yepnope/
There are some that think that this is bad though:
http://nefariousdesigns.co.uk/archive/2011/05/sniff-my-browser-the-modernizr-inadequacy/
My company wants to use SalesForce as its backend for a new Web application that we are building. We will host the Web application with an ISP on our own servers. The integration points mainly involve sending customer and transaction data via the API. In essence, the Web application will have its own database, but will send over customer and transaction data to saleforce at key points.
The plan is to use SalesForce as a backend, so that we can save some time in developing all of this. What I don't understand though, is how custom functionality is handled by SalesForce?
Let's assume that our application offers some functionality. How would we expose that functionality in the SalesForce application? Initially I had imagined we could reference this function/page (in our app) via an iframe from the salesforce app — but this does not seem to be possible... are there any other options?
So, to summarise, I need to show parts (or pages) of our web app in the SalesForce UI. If I can achieve this, it would mean that the customer services team can do everything in one interface (handle tickets, update user data etc.).
I am at my wit's end with this, it's even causing some sleepless nights. I would appreciate any useful advice!
If you create a visualforce page using a standard controller, you will be able to embed that visualforce page on page layouts of that object type. You can then iframe your web app into that visualforce page.
I.e. if you create the following visualforce page, you can drag it onto your case layout:
<apex:page standardController="Case">
<iframe src="http://your-web-app-url" style="width: 100%; height: 100%;" />
</apex:page>
You will need seperate but similar visualforce pages if you need your app on other objects than case.
Alternatively, you could expose your data to Salesforce via some API (xml or Json) and then build your application natively in Salesforce with apex and vf. This presents a different set of challenges, but the user experience is better in my opinion.
Consider using Force.com Canvas, now GA, which is an added-value iframe with more security and easier integration with Salesforce APIs than raw iframes - see https://stackoverflow.com/a/17484855/992887
Iframes should be possible - If you are using standard layouts, try creating Visualforce components containing iframes - like the example above.
If it is a simple application/part, I would recommend developing the application on Force.com itself - We have build some very complex enterprise level apps on Force.com - although I would add that Apex/Visualforce is an immature language for building complex apps and many times you will be dealing with its limitations. But once you make it, it works like a charm.