I have been developing phonegap applications that need to make updates oftenly. The problem is pushing a new ipa to iTune Store take too long. So, I uploaded the application source codes(minified javascript) to my server and download it from application and "eval" the minified js files. But i feel using eval has limitations and also not the right way. So, can someone tell me the right way to accomplish this.
thank you so much.
I'd love to have something like this as well. You're already ahead of me w/your eval() approach - but I'd have the same concerns as you there. Here's what I'm aware is out there on this topic - hope this helps?
IdeaPress(?)
I just recently caught wind of this one - not sure how feasible but it claims to do exactly what we'd like. I have to say the main site looks a bit flaky but I will definitly be checking this out to see if it's feasible or not.
HockeyApp?
HockeyApp (possibly dead-end now). I thought there used to be a pretty clear solution for PhoneGap devs to integrate the HockeyApp API/feature set with their mobile apps but a recent Google search on this is turning up much less than I would think - so maybe it's a dead end now? http://goo.gl/GQOv5o
org.apache.cordova.file
This requires more work and I haven't pushed far enough yet to see if it truly could be a means of updating the app post-app-store-deployment. But based on what I've read if you're just updating code for your WebView you shouldn't have to worry about App Store rejection or anything. Related tutorial
Testflight App Testing (Apple)
I haven't gotten to play w/this yet but sounds like it could be promising for at least the beta/testing phase of development. I, like you, need a solution for end-users, not app testers, but I'll still be looking into this soon as it might replace me having to maintain my own over-the-air app installs for the best/testing periods.
Related
Been reading up a lot on Isomorphic frameworks and curious as to whether Angular 2 can be considered "Isomorphic". It doesn't seem to be included on any lists, but that may well be because it's still very new.
I have read that Angular 2 is less tightly coupled with the DOM than AngularJS, but it does not however support server rendering. Judging from this link
https://github.com/mbujs/isomorphic-angular
Angular 2 doesn't seem to be classed as Isomorphic by default, however it looks like it is heading that way.
Very general question I know but just looking to see if anyone has any thoughts or opinions on the matter, or whether in fact it actually matters!
Thanks
It's looking to be like the creators of Angular 2 want it to be multi-platform (so, yes, server side rendering). If you browse their source code on GitHub you can see that they have a few modules for both server-side and browser-side "platforms" - a platform provides the bootstrap method to the library using Angular2, enabling it to start an application (think angular.bootstrap).
Unfortunately the server.ts is currently empty so it looks like right now, no, it is not isomorphic. It would appear that Angular2 uses an adapter pattern for connecting to the native browser API, so it's entirely possible that an adapter just needs to be written for the server side for this to work.
There's no feature tracking other than the issue that Gunter linked above, so that would be your best bet to keep tabs on the feature.
Interestingly there also appear to be source files for web workers.
Don't worry if you get lost navigating the GitHub repo, for some reason the Angular2 repo looks like it has been intentionally hard to navigate with mixtures of dart and ts everywhere
This document is old. It's planned for Angular2 to support server rendering, it might work already (don't know the current status).
See also https://github.com/angular/angular/issues/1810, https://angularu.com/VideoSession/2015sf/angular-2-server-rendering
Inspired by John Papa's video at Pluralsight, I started learning SPA. It appears pretty interesting. However, before I fully jump in, I'd like to clarify some of my questions.
From what I learnt, SPA is a lean server, fat client app. I think this should work well for small apps like what John Para demonstrated. Does it scale? How big it can be? Anybody has experience with this?
In SPA, you seem to code all the business logic in JavaScript. Is this a good idea at all? How do you hide the business "secret"?
With my background primarily in C#/WPF/.NET, moving to JavaScript seems to be very difficult (well, I learnt a little JavaScript more than 10 years ago - I hated it and never touched it again). With my limited knowledge, I ran into several problems. Debugging JavaScript seems to be a nightmare to me. The highly praised component Breezejs seems to be still in its early stage (e.g. it doesn't support UOW, doesn't support CascadeDelete, doesn't support enums). So, I'm wondering this is good time to jump in?
Directly to your questions:
Since the server logic is thin you can use some kind of cloud services and they scale pretty good. The most of the logic will be handled by the browsers of your users.
You should be careful if you depend on client. HTTP protocol can be easily manipulated. Don't forget that you should always do the validation logic both on client and server side! Also the "hidden" validation and other "secret" logic should be located only on the server.
Debugging JavaScript isn't so bad at all. You can use the built-in tools (Inspect element in Chrome and FireBug in Firefox, etc.) Also there are a lot of useful third party tools that will help you with the debugging.
If you start a new project just for your own use then I advice you to try the SPA approach. If you are writing production code you should become an expert in this area and then try to use these technologies.
Regarding UoW, take a look at the TempHire sample. It demonstrates using the UoW pattern on the client as well as the server.
https://github.com/IdeaBlade/Breeze/tree/master/Samples/TempHire
I believe SPA's provide a better framework for Business Intensive Applications as well as simpler application workflows such as that of Facebook. I have worked with Multi Page Applications for banking application with complex workflows and it get daunting to handle every thing and still keep up the application performance.
But I do think Knockout Alone wont be able to handle large applications as it is to connected in nature. I would recommend something like Backbone Marionete or Angular for that venture.
I am building a framework for large scale SPA development for the opensource community so I do believe it is the right direction.
Interested parties can go to my demo page at http:\saqibshakil.github.io I have demonstrated some of my work there.
i have been looking into it for months. My conclusion is to use Knockout with a light path.js or sammy.js for your url. I use json with a standard Visual Studio MVC ( which can return Json) as the backend.
I am still not done with the project but so far so good. It's lightning fast, elequent and lightweight.
Stay away from the frameworks. Get a look at the standard libraries: how they are written; You can learn a lot of JavaScript that way. Finally debug with chrome or explorer developer tools.
Good luck
Is there any scorm player which is purely based on the javascript and html . i do,t wanna use any server side languages for it . I found an open source Scormpool but it is just playing the scorm its not tracking . and no documentation is available . If you guys know any please help .
This may get you started as well, or you can tailor it to your own needs.
https://github.com/skfriese/simple-scorm-api
It's a rudimentary SCORM 1.2-only RTE test environment in a single HTML file that I whipped up for my own needs years ago. I only recently elected to clean it up to share with others. It's easy to throw into your package folder and spin up from there. The SCO will assume it's running in an LMS, which is really all that's necessary for testing most of the time.
You can update the default values in the Javascript, and the data will be stored in LocalStorage or fall back to cookies if necessary. It will also "attempt" to read some values from a manifest, should one exist. It does not support multi-SCO packages or any other complex organizational features of SCORM.
The Reload Tools have been embedded into the page as well, so you'll find that most of the data elements will be validated.
Hope this helps someone.
I was searching for similar solution myself and was unable to find anything.
So after struggling with docs and bits found online I have created this:
https://bitbucket.org/jugger0/tsp
It is far away from a fully-featured player but can be used as a starting point.
Maybe someone will find it useful.
It would be helpful if the desired result was better defined. Do you just want to be able to run scorm content locally without errors?
The initial question mentions that the content is playing but not tracking... where would it track to? Are you looking to have things stored for later retrieval on the same system, or potentially on any system? If this is the case, where would it be stored? In the browser (single system only and prone to deletion with clearing cookies, cache, etc), or to a server (accessible from multiple systems)?
If to a server, it is going to require at least some server side language, though you could potentially use something like node.js which would let that language still be javascript.
Claude Ostyn's SCORM 1.2 Test Wrap will act as a standalone in-memory "LMS" for SCORM 1.2 courses.
There is some setup required; though it will work if you run it directly in the browser, you may find it more effective running it (and your course) from a webserver.
Available here: https://www.jcasolutions.com/development/code-repository/func-startdown/7/
This used to be part of a resource kit from Click2Learn. Though Rustici (scorm.com) has adopted some of it, I wasn't able to find the original file there.
Instructions and more details may be found by running "launchme.html" directly.
I've found this one of my more valuable testing tools.
A SCORM 2004 version, and many more useful articles and tools may be found at Claude Ostyn's website http://www.ostyn.com. He passed away several years ago, but someone has kindly kept the site up.
One of the great things about being a web developer in recent history is all the sharing that's going on, especially with JavaScript libraries. There's all these awesome tools to use: jQuery, jQuery-UI, Lightbox, bxslider, underscore.js, Backbone.js, the list goes on. Then there comes a time when one or more of these libraries need to be updated. But JavaScript runs on the client, it doesn't compile, and it's difficult or impossible to be notified when a problem occurs. What is the best technique right now to assure that after you update one or more JavaScript libraries, your web application will not start throwing JavaScript errors?
There's no way the best response to this is to just test. Especially with a complicated application it can be too difficult to go through every possibility and make sure no errors are thrown. What are other web application developers out there doing to make sure they don't have a deployment with an embarassing and crippling JavaScript bug caused by updating?
The best answer is to "just test". What you are asking, essentially, is "How do I test to make sure my software still works?". You can do all the homework you want to see what changed, but eventually you just need to test your application.
That being said, there are generic testing tools like JSLint and Selenium, but ultimately your application is going to be unique enough that you will need to have unit tests to cover the business logic and standard QA for non-standard processes.
One way to ensure that things still work functionally is to have a suite of automated browser tests (utilizing a tool like Selenium) that you run on your development environment.
I wouldn't really call this "just testing" but unit testing will help do the job. Write tests once for your app looking for the expected results (good practice either way), then when you update the plugins run these tests again.
http://qunitjs.com/
Nothing beats a good QA and browser testing though.
Plenty of other answers already include "test", so hopefully that's obvious at this point.
The other thing that you should ALWAYS do is read the release notes for every single version up to the version that you're upgrading to. I can't speak intelligently about bxslider or Lightbox, but the other major libraries that you referenced are extremely good at releasing detailed changelogs which will notify you of breaking changes. You can decide for yourself if any of these changes will have a negative effect on your app ( in addition to testing of course!).
If you use either Sproutcore or Cappuccino for your frontend, doesn't it mean that everyone could see your javascript and copy it?
If so, they'll have your whole frontend code.
Am I right or wrong?
On the web, if you don't give your frontend code to your user, it's not frontend code. There is no reason at all to worry about that though - the web has been like that since day one and it has been doing just fine. Focus on making a good product and getting noticed.
You are right. The javascript in your web pages runs on the client - so it needs to be downloadable by the client. By definition, clients have 'your whole frontent code'.
The usual process of trying to make your javascript hard to read (and therefore copy) is called obfuscation. Obfuscated javascript is the same as non-obfuscated javascript to the browser - so it will work equally well with any javascript framework.
You are right. Also, this is true of plain javascript.
Keep in mind that the "compiled" Cappuccino / Objective-J code is very different to the original code so it's not really easy for anyone to copy parts from your Cappuccino app and reuse it.
Ultimately, this isn't really a big issue of concern. In most cases it's far easier to just rewrite the code than to try to copy the packed code from the source. The fact that Apple uses SproutCore for their MobileMe tools would imply that they've found the risk to be minimal. We all know how much Apple likes to keep things to themselves :)