PhoneGap Javascript Limits? - javascript

I'm looking to create a cross platform Mobile App and have been looking into Developing using PhoneGap. I'm an amateur programmer and most of my knowledge is in ASP.Net and C#.
Will only being able to use HTML, CSS and Javascript with PhoneGap limit me to specific functionality of my App? and would migrating to HTML5 help in adding more functionality to an App?
I'm looking to be able to Populate Drop-Downs from a Database, Add/Edit/Delete Items from a Database, Create Reports Ect...

Your only real limitation as far as data access goes is that you're limited to an SQLite database, which to be honest isn't much of a limitation since it performs great for single-user access.
The short of it is that you have access to a database from within your app, so you can do whatever you need to. The tools are HTML & JS as opposed to C# with some graphics layer, so doing things like creating graphs is quite different, but it's all possible.
Also note that depending on what your app is doing, PhoneGap is one of several solutions. If you want a "native" look/feel, consider TitaniumUI -- it takes common code (still JS) and pushes it through some translation layers to create native UI components.

Related

Possible Web Framework to Use in Existing Application

I work for a medium sized company that has an application used by a few thousand people and is built primarily with HTML,Javascript, aspx, xml, xsl, and runs on IE 11. This application is proprietary and not designed in house but we have access to the code for possible modifications and its just sitting out there on the server(s). A new project has come down the pipline for an enhancement\adjustment to be made to a particular area of the application and I'm wondering what kind of web framework I could use to do this work. I am really just needing to call an enterprise service and get data back, display it, and that's about it, so its not incredibly hard. I am worried though about how to integrate it with the existing application.
I am not sure how this scenario would go:
User navigates to page A inputs data, I want that data to go to a controller or something I built, fetch info and send it back to page A. I was thinking of using Spring MVC but not sure. Any feed back or suggestions would be greatly appreciated! I know this question doesn't include code, so please don't hate me.
Thank you.
From a very high point of view and with no knowledge about any specific requirement.
If you have already an application developed in ASP.NET, it's better that you continue the development of the new module of the application on the same platform.
If you want to develop a new module (actually a new web app) that looks like the old application but with a totally different platform like Spring MVC (could use any other), you can reuse the existing css styles and databases.
For integration purpose you could modify the original application in the menu(or links) that redirects you to the new module and implement a single sign on server (this will required work on both applications) to made the transitions smoothly between both applications (something like a portal style). Note that they will have a different context application path.

Testing framework for ASP.Net modules + Javascript

I inherited a large framework (my employer purchased a product) that uses ASP.Net modules (.ascx files loaded dynamically by Default.aspx). The product did not, of course, come with its tests (at least, I assume the product has tests).
Because the ASP.Net postback client-side experience is awful, I've started adding more modern, Javascript-heavy functionality both to the existing modules, and in the new ones I create. Due to how the system works I really cannot move away from the module-driven framework currently in place into an MVC setup.
I'm looking for a test framework that can access both the browser and the back-end framework. I think I've come up with a set of requirements for this framework/combination of frameworks:
MUST handle navigation to multiple pages (wizard-like behavior).
MUST handle new window popups.
MUST handle DOM manipulation via Javascript (showing/hiding elements).
MUST emulate mouse/keyboard input on pages.
MUST be able to query/validate Javascript variable states.
MUST be able to query/validate back-end SQL Server.
MAY be able to query/validate back-end ASP.Net state. (Nice to have.)
Ideally it would have integration with VS's Test Explorer, but that's not a hard-and-fast requirement.
Does such a framework exist? The google searching I've done has come up with plenty for single-page Javascript-driven sites, MVC sites, and plain ASP.Net sites without pretty Javascript, but I've had a hard time finding (or recognizing) a framework to fit my needs.

Angular/React - Where do they fit in?

I would like to start looking into Angular or React, but I'm having a hard time at the minute figuring out where they fit in?
I currently build all our sites using PHP based Expression Engine or Craft CMS. Is it possible to use Angular or React with these? Would I be correct in thinking they act as the whole front-end?
So for example, would I use EE/Craft to just create the API's to fetch/post data, and then Angular/React would generate the pages using the data from these calls?
That is exactly what I would do. I am not overly familiar with the CMS frameworks you are using, but do have a good bit of experience with CMS development. Typically I leverage the provided APIs to bring the data to the presentation layer, and then use a JavaScript framework such as Angular to create my UI.
This approach will work great if you can get away with not using any of the CMS server controls, and perform all data operations through API calls.
Using a CMS for your data as an API is fine, but you might be better off with something custom made (like a rails or nodejs project). CMS's are not ideal if you're are building just an API. Typically, you'd built your React/Angular website as a static website that you can deploy to a hosting provider (like S3 or Github Pages), this gives the immediate benefit of improved security, speed and scalability. From your static React or Angular site you then leverage your server-api's to fetch the data.
However, this only fixes the data problem, not the content management problem. Since you have a static site, there is no way for your content editor or marketers to be able to change the content on your website. Everything has to be done in the source code - by a developer. You can fix this by adding a drop-in content management solution like INSTANT on top of your static website. Without any coding, it allows anyone with an account to change content directly on the website.

Providing no-js fallbacks for clientside MV* frameworks

I just recently got introduced to MV* frameworks and have taken a chance to try out Ember.js with the TodoMVC app tutorial they have on their site.
I was considering using Ember for one of my upcoming projects (a Ruby on Rails CRUD app, similar to Twitter in some of the functionality), but I'm still a bit confused and before I take a final decision I would love it if somebody could clear the following concerns:
Is it a good idea to use such an advanced framework as Ember for a medium-sized multi-page CRUD app? Will it improve development time and maintenance compared to an interactivity layer built with jQuery's DOM manipulation and AJAX capabilities? Or is using Ember (and the like) only good when developing complex single-page apps (e.g.: Grooveshark)?
Considering the app will be developed using Rails, and assuming Ember will be used, is it going to be possible to offer a fallback with basic functionality for browsers with JavaScript disabled and/or for search engine crawlers? Will it require code duplication or other dirty tricks? Do you know of any technique that can be used to achieve it?
Will it be possible to adapt the website for mobile browsing (using only CSS) with valid results, or will the overhead imposed by running Ember on the phone make it hard for the device to render the website in a way that keeps it responsive?
We're in the middle of a pretty big Ember project right now, so here are my thoughts on your questions.
We've found Ember to be really productive for creating rich UIs for our single page app, but I don't know that it's going to be that much more helpful if you're creating an app designed for traditional multi-page (viewing pages, submitting forms, etc) layout.
I think this is the clincher - Ember is completely JS-based, so if you need to support browsers without JS, you'd basically have to write a parallel application. If this is a hard requirement for your app, I think Ember (or any MV* JS framework) would be out of the question
We've had very few performance issues on mobile - our site is fully responsive and renders on everything from Blackberries to the latest Chrome on desktop with good performance.
#Scott Rankin, has addressed most of the concerns with going with the Pure Ember approach. I'll add one quick way to make this decision.
Go with Ember/MVVM if the application is behind a login. Then you don't have to consider search engines, as the content is generally private and not supposed to be indexed.
For SEO you have to build atleast part of your content such that it is indexable. A good example of this is the Discourse application. They use Ember but also send down some generated html along with the app html slugs, so that search engines can index them. You can read about their approach here.
We have a different approach which can be seen as a fall back: We pre-render a static version of each page in the application (daily scheduled task). This static version is stored on the server as HTML file. Whenever we sniff as spider/ robot user agent, we deliver that version.

Pure JavaScript-based clients

I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?
My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.
How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.
Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.
Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.
I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:https://beebole-apps.com?demo
So yes it is powerful and viable.
Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?
You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)
However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...
Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.
Disclaimer: I'm a member of the Vaadin team.
Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.
Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.
I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.
In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.

Categories