I am planning to use node webkit for porting my existing html/css/javascript from a web app to desktop native app.Before doing this, i was trying to see if there are any downsides of using node webkit.
Which is the best database supported by nodewkit
My understanding is that it does not require any browser to run this node webkit app and that it provides webkit engine and the app provides a UI to it by using html5, and css.Is this understanding of mine correct?
All your pointers will be helpful.
Thanks!!!
Yes that is correct. Node webkit works as an HTML5/Node.js application wrapped around simple browser app written on Chromium Engine, and it doesn't need anything installed to work.
As far as I understand You want to connect to remote database, not create a local one for user data. If that's true, You shouldn't implement it on client side, but on server side. Which means your server side implementation shouldn't differ from Your actual one.
I create some applications with the following struct :
- folder : server (for any php/db request or response)
- folder : client (for js/css and images)
the relation beetween the client and the server is AJAX.
and the best db for a local use I prefer : Sqlite (in a network MongoDB or MySQL)
in all the cases it's preferably to use an ORM like Doctrine.
and make sure that in the response of server you send allways a json (not a formatted divs or any html) the client must be able to organise his data him self.
as a sample : openerp use this structure (with python istead of php).
for use of sqlite here is link that explane the way:
http://tejasrpatel.wordpress.com/2011/12/29/create-sqlite-off-line-database-and-insertupdatedeletedrop-operations-in-sqlite-using-jquery-html5-inputs/
that's the advices from my experience. and hope this be helpfull for someone.
I am currently developing a node-webkit app myself as well. I had this same question so as I was looking around I found PouchDB. This looks very promising for a node-webkit environment so that's what I'm going to be using. I hope this helps you out as well.
Actually there is one major part of node-webkit that you don't mention in your question, that is the 'node' part, specifically node.js. This is important because just about anything you can do in node.js is available to you in node-webkit.
I don't know what your application does, so I can't tell for sure, but you may or may not need an actual database. If all you want to do is store some data, you may find a file to be sufficient (JSON or whatever format is convenient for your purpose) which is easy to do with the fs module. Or you might only need to use localStorage, which is also available in the 'webkit' part of node-webkit.
If you do actually need a database, then anything works with node.js should be available to you, such as the aforementioned pouchdb, or any number of other possibilities.
In any case, you don't need to set it up as a client server model if you don't want to, you can just access files or databases directly in your node.js code. Conversely, if you do want to do a client-server model, you can have both running locally within your node-webkit program.
Hope that helps.
I use node-webkit insted of Qt, PySide, etc. and I tell you why:
webkit (the most full feature browser)
nodejs (what can I say is javascript)
cross platform (almost all)
To package and distribuite the software I use Web2Executable
For the GUI I use ExtJs 4.2 from Sencha
Database (engine) I use NeDB but you can use internal engines from webkit found here persistent-data-in-app
Related
For one of our clients we are building a web application with oracle adf.
One of the requested features of this application is having a drag-and-drop file upload.
Fortunately the af:inputfile component supports this feature out of the box.
Unfortunately that feature is not supported in Internet Explorer 11, which we absolutely have to support.
Now I have been trying to get it to work using the dropzone.js library and the drag and drop functionality seems to be working. but I haven't been able to get the POST request to the ADF side of things quite right.
Even if I did it would be a lot of custom code that would have to be maintained, if it's the only way to make it work that is fine but if there is a more elegant solution to this I would like to know.
What you can do is to use ADF JavaScript APIs, more specifically AdfFileUploadManager(https://docs.oracle.com/middleware/1213/adf/api-reference-javascript-faces/oracle/adf/view/js/util/AdfFileUploadManager.html)
You need to instantiate it by giving it the ADF Component reference, which that can be an af:inputFile with display="none"
Then you can utilise your DropZone or any other functionality and use addFileToQueue to send this information to server side and convert it to UploadedFile.
At the moment I am making an app. I am relatively new but have experience with a lot of different languages like PHP and SQL. My app needs to communicate with a server to post/retrieve data for everyone to see. People also need to be able to login and register. Right now I am using parse because it gives a lot of the requirements in an easy package but parse is retiring soon and I have no experience with setting up my own server.
I was thinking of making my own 'server' from an old computer but not use parse because it will no longer support push notification. Then of course the app needs to communicate with this server. I started looking online and found a lot of terms but not a real clear explanation on how to proceed. I need it to be able to communicate with iOS and Android. Furthermore I was wondering how to execute a script on the server itself. I want to do something with time, once someone uploads something it needs to disappear after 48 hours, but of course it also needs to do this even if the app isn't active on a smartphone
Can anyone tell me how I need to proceed, what to use and where i can find useful info.
My plan for now is creating my own server with something like MongoDB but then i still need something called a backend and different SDK's to communicate with the apps. Maybe its possible to install parse on my own server and add something so i can still use Push and run a script on the server itself.
All help would be very much App-reciated ;)!
The reason of a backend service or framework is to let developer focus on front end app development. Maybe you can check other options like firebase, meoter, or even leancloud. Don't be hurry jump to the decision to make your own backend.
Parse Server is already supporting Push Notifications. I think should keep using Parse. It will become the best framework for backend and API development in a short time. You can also use services like https://www.back4app.com that helps you in all process of configuration of your server.
Do you mean by create your own server running a personal derver pr you mean create your own back end application?
I have a logistical question: I'm trying to figure out the best way to manage APIs getting out of sync with an app. The best way to explain it is with an example:
Let's say MyApp Version 1.0 posts to a "submit_feedbacK" API that requires first_name, last_name, and email.
I then submit MyApp Version 2.0 to the App Store. That version is designed to post first_name, last_name, gender, and email to the API. All of these are required fields on the API.
The problem I have:
- If I update the API before the new App is live, it will break Version 1.0
- If I wait until Version 2.0 is live and remotely cripple 1.0, I have to time it correctly.
I'm going to guess that the 'right answer' is to maintain two different APIs. But if both APIs post to the same live database, that makes things a bit awkward.
Does anyone have suggestions on how to model this?
This question may share some aspects with iOS consuming API design.
The right answer is definately to provide two APIs (at least for a short period of time while users adjust). You do not have to maintain two versions at the same time, as once a newer version is released you can maintain that one, and simply provide the old one for legacy users. The only real changes you may have to make to it are things like security patches or major issues. Major changes (such as you deciding to restructure your entire database) may lead to the old version not working any more, however update to newer API versions should be designed to allow previous versions to still function.
The other question I linked you to gives an answer about how you can have different version of your app access the correct version of the API.
Another note is that it may be easier for you (depending on what framework you're using) to design your APIs as engines or subapps, and simply mount them at different end points. I know that this is easily do-able in Rails by using Engines, and in Node with Express using app.use() with sub-applications.
I would use a webservice/http endpoint for the communcation with your app. If you preferer to maintain the same URL in all versions of the app, then include a version number in all the requests/posts to the server so it knows how to handle them. This will also make the development and tests easier as new versions can test against the new api on the server.
So on any function you can call in the webservice/server add a single variable with version number. a BYTE ought to be enough as I think you could start over and "kill support for v1.0" once you hit 256 versions of the same function (if ever).
Once the server receives a request/post with data, you can just code a simple switch/case structure in the server API so support works for both versions.
If they do similar, but eg. swaps the parametres or something, you can handle all these serverside and the BAL/DAL (n-tier structure) can be maintained on the server part of the solution.
Btw. my answer is not just for iOS or smartdevices, but merly a client/server approach for a "work-in-progress" production setup where everything has to be online, while still being under development and maintanance.
Hope it makes sense, otherwise, comment on it and I shall try to explain it further.
just FYI, I use CodeIgniter. I'm using the REST Controller provided at https://github.com/philsturgeon/codeigniter-restserver. I ultimated ended up settling on having different end-points for every version. Basically I'd check out a new repository for each release and put it into a unique directory. (i.e. http://www.mysite.com/1.0/api/method, http://www.mysite.com/1.1/api/method, etc) Trying to maintain multiple versions of an API under one code-base just sounded too scary. At least when I released a version, I would know it is locked in stone and I don't have to worry about breaking it. (Note: I had to use a special .htaccess tweak to get multiple CodeIgniter instances running from the same domain. I can share it if you like)
Im trying to make a upload progress meter that works on ALL modern browsers in all operative systems (hence that I don't want to use SWFUpload, since all the demo pages fail in my computer, since I use Ubuntu).
Could someone give me please a hint where to look? I've googled the internet up and down without a solution...
Im running a server with PHP, but APC didnt work, apparently doesnt play nice with lightppd. Also I don't know Perl, so I'd rather not having to learn it for this.
I did this using ASP.NET not long ago. Basically, there's no pure HTML way to do it. What needs to be done, is to make changes on your server (in ASP.NET, I wrote an HttpModule to cache the current status of the upload - for PHP, Ruby, etc, there's likely similar methods to plug into).
Then on the client side - when a file was being uploaded, I made periodic ajax calls to the server to access the upload data that the server was caching. Then, using javascript, I would update whatever HTML progress bar.
You can see plUpload : http://www.plupload.com/
If you're using AJAX, you could go with this solution. And here are a few using jQuery.
I have written a simple database driven app in C# which uses a 2 table MySQL database. This is all a learning curve for me (except c#, which I am now comfortable with)
The app is small, has a couple of datagridviews, uses a few sql select/inserts statments to populate the datagridviews and also update records.
I want to port this app to Android. All of the internet sources I can find recommend a middle php sript which accepts http requests in order to fetch the data from MySQL and then return the results back to the android device where it is parsed with JSON etc etc.
This method is a little out of my reach since I dont have php experience, all of my attempts to implement the php layer have failed, speciially the android app was not receiving any data back, I'm assuming I messed up somewhere inside the php file.
Is there an easier (more noobproof) way to interact with the MySQL database from within android which doesnt require the need for php + JSON? Any ideas are appreciated, thank you in advance.
If you are comfortable with C#, why not use ASP.Net MVC for the middle man?
MVC is especially easy to deal with JSON, and you actually only need to create those "controllers" (as models should already be there from your existing app, and JSON don't need the View to display).
You can create a Web Service with C# that handles the data retrieval from the database; no need to go with PHP. Try create one with WCF API (check this question in order to create one). In order to create an Android client that consumes JSON on Android check this link.
If your mobile application have to access a database over the network you should indeed build a web service fronted to the database.
By putting a web access layer on top of the database you can expose the required queries in an abstracted, secure and convenient manner.
Though this sort of web service architecture can be implemented with PHP + JSON other technologies can be used as well. If you feel more comfortable with C# you can use it to build the web service instead. By doing so you may even be able to reuse some of the code from your existing application.
Actually, it would be better to take php in middle of android & mysql, due to the security concern and by the way this is the most easiest & comfortable method. here is link link. I hope you like it.