I have been looking online and there are some articles about people using Django web framework and Phonegap to build mobile applications.
However, it says on phonegap to upload your HTML, JS, and CSS files to the build. Does that mean you cannot use django to build mobile apps with phonegap?
Any clarifications or steps on how to build would be great.
Think of PhoneGap as preloaded static web pages in a WebKit view. You can add JavaScript (most people use JQuery/JQueryMobile) to make it dynamic and use AJAX calls to load data from a server but rendering templates is not what it does. You can do fragments but it's not the same thing as Django Templates.
I am working on a project that handles data loading via an API from a server running Django. The App is being written in PhoneGap and uses AJAX calls for getting the extra data. I'd say look at django apps like TastyPie for helping get data. The main goals in using PhoneGap are 1) better load times of HTML since it's local, 2) Reduced traffic by only sending API data and thus better for cellular networks and 3) access to native feaures in the hardware you don't otherwise get access to with JS in a webpage.
Related
What is the best/efficient way of creating a mobile app out of a Django site. I understand that perhaps using React to and connect to a DJANGO API, but assuming I don't know React, can I somehow convert DJANGO site into a Phone Appp?
Short answer - You shouldn't because there are better ways to build mobile apps with Django as your backend.
Long answer - You could use webview in android to wrap your web application. Depending on you app, you might need to use some native code to build any of your floating action buttons, bottom navigation, toolbars etc while keeping the rest of your Django app wrapped in the webview. The downside is that your app will lack real performance gains or full native features that you’d be able to utilise.
You could also convert it to a Progressive Web App which will be your django app given some super powers to be able to provide content when a user is offline on both desktop and mobile. Check out Django PWA for this.
I would like to create a React SPA, which is fed by querying a Django REST API.
I was reading this, and I encounter this point:
I see the following patterns (which are common to almost every web framework):
React in its own “frontend” Django app: load a single HTML template and let React manage the frontend (difficulty: medium)
Django REST as a standalone API + React as a standalone SPA (difficulty: hard, it involves JWT for authentication)
Mix and match: mini React apps inside Django templates (difficulty: simple)
It seems that in case of an SPA (Single Page Application), it would be better to choose 1. As far as I understand, the React app would just be a big file with all the required css, html and js, right?
So we just create this file, and serve it on a specific endpoint of the Django app. Then, I do not understand the benefits of the "standalone" way of doing things. We would need two different domains, it would cause issues with authentication, and the standalone SPA would in fact just be serving a static file right? Is there a reason why it would be interesting to use a standalone SPA?
But when I read React in Django or React as a standalone?, it is advised to keep front-end and back-end separated. I wonder what I am missing, and what is the benefit of creating a standalone React SPA. reactjs - React in Django or React as a standalone? - Stack Overflow mentions that it would allow backend to be reused by different applications, but I do not understand what would prevent my backend from being reused if it is serving a static file. My backend will not disappear, it will still be here, ready to be reused, right?
pt1. yes the react app is bundled into a couple of files that you can use in your html template
pt2. standalone would be interesting if you already have a large Django project running, and you cannot afford migrating everything to a React SPA
pt3. You are correct in stating the backend is just another application serving content, and can be accessed like any other API. The difference lies in the content being served: When creating a React SPA, the backend is only concerned about what data is requested and what data needs to be persisted to the database. Now your frontend code can focus on specific frontend problems, such as user experience and browsing/navigation of the user: For example utilizing the Redux store, where you can store your JWT token in the browser session, or cache already retrieved data that might be useful on other pages. This offloads the backend considerably because you don't need to send the same data twice.
I have made a web-app using django framework and stored it on heroku.
How can i combine phonegap so that I will be able to create both iOS and Android application that will simply load my hosted website?
I'm having an hard time knowing how to combine both technologies (django and phonegap) together, because phonegap requires the "index.html" and i dont know how to make it navigate to my main page.
And i dont know what "Procfile" to use in order that the heroku server will know how to react both.
I have seen somthing involves rest API for django. I found it hard to understand why should i add it for my website...
A tutorial would also be great !!
Integrating phonegap and django is a pretty broad topic covered here and in this tutorial.
For setting up multiple stacks on the same heroku app, you will probably want to use buildpack-multi.
I will be developing a mobile app (iPhone) and a web based app (Django) soon. For the mobile app I will be creating a REST api (most likely using Django) to send data back and forth from phone to server.
When I comes time to create the web based version does it make sense to just create it as any other client of the api. In other words both the mobile app and the web app will get there data from an external API over HTTP. Or should the web based app have direct access to the database that the api is using and just get its data that way?
Break it into three "sections". The first uses a Python API to manipulate the database. The second interfaces your REST API with your Python API. The third talks web and uses the Python API.
I would create the web application to serve the API to the mobile client. That is, give the web based application direct access to the database. This will simplify your XML / JSON RESTful resource access.
I would say no, don't use the API for the HTML version. If you design your Django well, you can end up with less code than using the API for the HTML version. You also get to retain the ability to have a web designer work with the Django templates whenever the boss wants the spelling changed on something.
I'd suggest trying to define a base app for your iPhone app to interface with, and then extend that within a second app for the HTML version. App1 would have all of your models (including business logic), and a views.py for processing the data to/from the iPhone. Then create App2 which uses App1.models, but creates its own views.py. With any luck, you'll find yourself with the ability to change nothing but the template used to render the output, so you can reuse your views by passing the template as an argument.
For example:
App1.views:
def list(request, template="list.json"):
list = Model.objects.filter(deleted=False).filter(user=request.user)
list.reverse()
## Lots of other logic to work on the list.
return render_to_response(template, {list: list,})
App2.views:
def list(request, template="list.html"):
return App1.views.list(request, template=template)
I think the answer to this question has changed over time. A year ago when asked it was probably still too much hassle to do this, but now I'd definitely say yes - using your API as the basis is the smart thing to do. As Web sites use more HTML5 and Mobile apps get smarter it really makes sense to have all your "UIs" read/writing from the same API layer. This will give you much more flexibility in the future.
I'm sending a lot of JSON requests from a native iPad application to my Django web server. How do I translate forms I use on my website to handle an iPad web service?
Am I trying to solve the wrong problem, should a web service used from native iPad applications be redesigned to use REST-ful requests?
Well, first of all, this question should really be:
"How do I write a RESTful API using Django and JSON?"
iPads are just like any other web browser (client), and they can use javascript, JSON, etc.
Here's a high level description of what you need to do:
Write a Django view and map it to a URL, eg: /api/some_action/
Write out the body of your view, have it perform whatever action you need on the server.
Write the HTML/javascript code which is displayed on a user's iPad, so that when iPad users visit a part of your website (let's say /home/) they'll make a JSON request to your server which talks to the API (eg, sends some JSON to /api/some_action/)
Once your Javascript code sends JSON to the API view, your view should process that JSON, and perform whatever actions you want.
This is the way most web-services are developed.
Hope that helps!
Can the iPad (or iPhone/iPod) browser send PUT/DELETE commands? For me that's the biggest trouble when trying to do REST-like apps in JavaScript.
In the end, what i tend to do is to have small Django views (mostly using the create_update generic views) to handle the HTML/form/model integration; and in JS, i use jQuery's $('#dialog').dialog().load('dialogurl') to open a dialog and load it with the form generated by Django. Be sure to either manage the submit() yourself.
I'd prefer a lot to just write a REST server (probably using Django-Piston) and a full client app on the browser; but so far i haven't found a nice enough JS framework. (pyjamas or qooxdoo sound great, but fall 'just a little short')
Django TastyPie address this need - RESTful and Ajax suitable for iOS (iPhone/iPad) and Android Tablets.
http://django-tastypie.readthedocs.org/en/latest/index.html
http://django-tastypie.readthedocs.org/en/latest/tutorial.html#adding-to-the-api
This makes even more data accessible, so if we start up the runserver again, the following URLs should work:
* http://127.0.0.1:8000/api/v1/?format=json
* http://127.0.0.1:8000/api/v1/user/?format=json
* http://127.0.0.1:8000/api/v1/user/1/?format=json
* http://127.0.0.1:8000/api/v1/user/schema/?format=json
* http://127.0.0.1:8000/api/v1/user/set/1;3/?format=json
* http://127.0.0.1:8000/api/v1/entry/?format=json
* http://127.0.0.1:8000/api/v1/entry/1/?format=json
* http://127.0.0.1:8000/api/v1/entry/schema/?format=json
* http://127.0.0.1:8000/api/v1/entry/set/1;3/?format=json
Here's demo
https://github.com/natea/Valentunes
It is has a web client iPhone app (search it).