I have an iOS app in which I use parse.com as backend service. Now, I hired someone to do a website interface using HTML and CSS. I want to share the same data between iOS app and website, I know parse.com offers me a few ways to do this, including creating a javaScriptapplication. The problem is, my programmer doesn't have any experience in JavaScript, nor do I.
My question is: Is it possible to use what I have (objective-c, xcode) as far as retrieving data from parse.com and showing on website? Even if I need to code something new, is it possible to use objective-c together with HTML and CSS?
Thanks.
Parse has several APIs, one of which is REST. Your web developer should use the REST API to get data from Parse
https://www.parse.com/docs/rest
If there is will there is way, but you'll be making something really specific to your use and will be non standard and will be immediately hard to maintain, I recommend that you hire another developer and do things properly using the technologies given to you by parse !. if the cost will be high now I can promise you it'll be much higher if you went the path you're going to now.
So my answer is:
Yes, everything is possible and no, don't do it ! :)
Edit: Added an example to a possible way to do it to actually answer OP's question.
Example case:
1-Create a simple Mac Application in Xcode that fetches data exactly like you do it on iOS, and store the needed data into a database of your choice on your server
2-You now have access to the data you needed from parse, but on a local mirror. you will need some tool to fetch that data though, I recommend a simple PHP script.
Note that this will require an OSX server to always be running to fetch that data, you'll also need of find a way to fetch data on demand when a user needs it Vs. polling at specified intervals, this will hardly scale and will be costly as I said.
I have been tasked with creating something that summarizes and displays information from a database (that is stored either in an SQL server or as an .mdb). I cannot convince my company that we need to use an actual application for this, since I am apparently the only one that understands Visual Basic or C#. All of the other programmers know only HTML and Javascript, and since they're worried about making something that only one person can maintain (can't say I blame them, since I'm not looking forward to being the only person who can answer our customer's questions), these are the languages I'm limited to.
I've had a fair amount of success in creating ActiveX ADO objects for manipulating databases, but it's my understanding that this function won't work at all in browsers other than IE. Since I'm absolutely sure that this will be their next demand of me, is anyone aware of any way to read databases (stored locally on the computer displaying the page, in a shared folder on the network, or in an SQL database on that network) in non-IE browsers?
I've found various plugins to allow these sorts of things; this might work as a last resort, but I'm really trying to avoid having to tell the customers that our app will only work if they install some random plugin.
Any ideas?
To open .mdb databases in JavaScript, you can use: AccessDB, it's a library to work with Access databases in JavaScript:
http://accessdb.sourceforge.net/
To fire queries at a SQL-server in your network, you could probably use: HTML5Sql: http://html5sql.com/
I haven't used the latter before though.
I was looking for a similar type of thing a while ago and also found the AccessDB JavaScript file. From what I understand, it only works in Internet Explorer because of the way the ActiveX objects work, as you mentioned. I would love this to work in Chrome but I have not yet been able to get it to work in Chrome.
That said, I used the js file to produce some applications that pulls data from the database very well. I use Access to formulate the queries since the SQL is a little different. I've been able to do just about anything including crosstab queries and export the data to html tables with ease.
So I got a new GeeksPhone Peak, and started making apps in HTML5, CSS, JavaScript.. It is great, I love it, but now I'm trying to make a timetable app and I have to save data, when I fill my timetable (just text) somehow, and reload it when the app is loaded.
I started searching and found localStorage, IndexDB, backbone.local-storage but couldn't really find great tutorials on them. Or is there a special API for that case? Can someone help me on which one to use, or how to write to file, save it, read it, etc.?
FirefoxOS provides multiple mechanisms for supporting persistence in your application. While considering the choice between local Storage and Indexed DB, your decision will rest on how important the following points are for your application:
How easy the API is use [Local Storage is easier. Simple key-value pairs]
Synchronous v/s Asynchronous API [Local Storage is synchronous. IndexedDB has both modes]
Transaction Support [Indexed DB has it]
How easy it is to do Search [Since local storage is just key-value pairs, it is difficult to do searches especially if your values contain complex structures]
A good article that provides comparison is here.
In case, you want to take a look at how to use the localStorage, IndexedDB APIs on FirefoxOS, I have written tutorials on the same: localStorage & IndexedDB & Device Storage.
I am looking to simplify some of my code which is implementing a pretty simple schema and I discovered this IndexedDb spec which isn't yet finalized.
The schema is used to present a table to the user with a filtering mechanism and allow the user to add/edit rows of the table. It doesn't need to stay persisted to the client (but that will make for less traffic when it is available). Thus I feel confident that I could use an implementation done fully in JS and could gain the benefits of a native implementation when it exists (presumably increased query speed and local storage).
I am aware of http://code.google.com/p/indexeddb/ but I am under a requirement to do this in such a way that nothing needs to be installed.
Have I gone mad or is there something to this?
IndexedDB is not implemented in any major browser ATM. I think Firefox 4 may be testing it -- http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/
Edit: I didn't read -- you want a pure JS implementation; sorry.
With the increased power of JavaScript frameworks like YUI, JQuery, and Prototype, and debugging tools like Firebug, doing an application entirely in browser-side JavaScript looks like a great way to make simple applications like puzzle games and specialized calculators.
Is there any downside to this other than exposing your source code? How should you handle data storage for this kind of program?
Edit: yes, Gears and cookies can be used for local storage, but you can't easily get access to files and other objects the user already has around. You also can't save data to a file for a user without having them invoke some browser feature like printing to PDF or saving page as a file.
I've written several application in JS including a spreadsheet.
Upside:
great language
short code-run-review cycle
DOM manipulation is great for UI design
clients on every computer (and phone)
Downside:
differences between browsers (especially IE)
code base scalability (with no intrinsic support for namespaces and classes)
no good debuggers (especially, again, for IE)
performance (even though great progress has been made with FireFox and Safari)
You need to write some server code as well.
Bottom line: Go for it. I did.
Another option for developing simple desktop like applications or games in JavaScript is Adobe AIR. You can build your app code in either HTML + JavaScript or using Flash/Flex or a combination of both. It has the advantage of being cross-platform (actually cross-platform, Linux, OS X, and Windows. Not just Windows and OS X).
Heck, it may be the only time in your career as a developer that you can write a web page and ONLY target ONE browser.
SproutCore is a wholly JavaScript-hosted application framework, borrowing concepts particularly from Cocoa (such as KVO) and Ruby on Rails (such as using a CLI generator for your models, views and controllers). It includes Prototype, but builds plenty of stuff such as sophisticated controls on top of that. Its Photos demo is arguably impressive (especially in Safari 3.1).
Greg already pointed you to Gears; in addition, HTML 5 will come with a standardized means of local storage. Safari 3.1 ships with an implementation where you have a per-site SQLite database with user-settable size maximums, as well as a built-in database browser with SQL querying. Unfortunately, it will be a long time until we can expect broad browser support. Until then, Gears is indeed an alternative (but not for Safari… yet!). For simpler storage, there is of course always cookies.
The downside to this would be that you are at the mercy of them having js enabled. I'm not sure that this is a big deal now. Virtually every browser supports js and has it enabled by default.
Of course the other downside would be performance. You are again at the mercy of the client handling all the intensive work. This also may not be that big of a deal, and would be dependent on the type of app you are building.
I've never used Gears, but it looks like it is worth a shot. The backup plan would be to run some server side script through ajax that dumps your data somewhere.
Not completely client side, but oh well.
Nihilogic (not my site) does a lot of stuff with Javascript. They even have several games that they've made in Javascript.
I've also seen a neat roguelike game made in Javascript. Unfortunately, I can't remember what it was called...
If you want to write a standalone JavaScript application, look at XULrunner. It's what Firefox is built on, but it is also built so that you can distribute it as an application runtime. You will write some of the interface in JavaScript and use JavaScript for your code.
Gears might provide the client-side persistent data storage you need. There isn't a terribly good way of not exposing your source code, though. You could obfuscate it but that only helps somewhat.
I've done simple apps like this for stuff like a Sudoku solver.
You might run into performance issues given that you're completely at the mercy of the client's Javascript interpreter. Gears would be a nice way of data storage, but I don't think it has penetrated the market that much. You could just use cookies if you're not fussy about that kind of thing.
I'm with ScottKoon here, Adobe AIR is great. I've really only made one really nice (imho) widget thus far, but I did so using jQuery and Prototype.js, which floored in such wonderful ways because I didn't have to learn a whole new event model. Adobe AIR is really sweet, the memory foot print isn't too bad, upgrading to a new version is built into AIR so it's almost automatic, and best of all it's cross-platform...they even have an alpha-version for Linux, but it works pretty well already on my Eee.
Standalone games in GWT:
http://gpokr.com/
http://kdice.com/
In regard to saving files from a javascript application:
I am really excited about the possibilities of client-side applications. Flash 10 introduced the ability to create files for save right in the browser. I thought it was super cool, so I built a javascript+flash component to wrap the saving feature. Right now it only works for creating text based files (vcard, ical, xml, html, css, etc.)
Downloadify Home Page
Source Code & Documentation on Github
See It In Use at Starter for jQuery
I am looking to add support for non-text files soon, but this is a start.
My RSS feeds have served me well- I found that Javascript roguelike!
It's called The Tombs of Asciiroth.
Given that you're going to be writing some server code anyway, it makes sense to keep storage on the server for a lot of domains (address books, poker scores, gui configuration, etc.,.) For anything the size of what you'll get in Webkit or Gears, you can probably also keep it on your server.
The advantage of keeping it on your server is two-fold:
You can integrate it fairly simply as a Model layer in a typical MVC framework, and,
Users get a consistent view without being tied to their browser/PC, or in a less-than-ideal environment (Internet Cafés).
The server code for handling this can also be fairly trivial, particularly if it's written with this task in mind, so it's not a huge cognitive burden.
Go with qooxdoo. They recently realsed 1.0, although most users of it say it was ripe for 1.0 at least two versions ago.
I compared qooxdoo with YUI and ext, and I think qooxdoo is the way to go for programmers - YUI isn't that polished as qooxdoo, from a programmer's point of view and ext has a not so friendly licensing model.
A few of the strong points (for me) of qooxdoo are:
extremely clean code
the nicest OO programming model I've seen among Javascript frameworks
an extremely rich UI widget library
It also features a test runner for unit tests, an API doc generator and reader, a logging facility, and several useful features for debugging, grouped under something called Inspector.
The only downside is that there aren't readymade themes (something like skins) for qooxdoo. But creating your own theme is quite easy.