Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
My plan is to make an app for iOS (and android when I've figured it out on iOS) in flash. I need to access data from an external mySQL-database that I will be putting on a webserver. I'm wondering what the correct way to go about this would be.
I've looked a little into AIR, Flex and JSON, but I need someone who knows what they're doing to put me on the right track. I don't need a super in-depth guide, just a hint in the general direction, I can do a lot of research myself, but I'm quite inexperienced in the whole accessing-external-databases-from- flash thing.
Thanks a bunch in advance!
-Flash Newbie
To access an external database you wouldn't use Flash directly, you would need some sort of middle layer (like PHP or Node or Ruby, etc) to get results out of the database and return them to Flash in some format it can understand (like XML or JSON.) This is commonly referred to as an API - it's kind of like a web site but it returns data in code instead of user readable html.
So the flow would look something like this:
Your iOS app would make a request for a url - something like this: http://myserver.com/users
You would have a server-side app (let's say PHP) deployed to a server handle that request.
PHP would query some database (like mySQL) and get the results. Those results would be formatted as JSON or XML and returned.
Your iOS app would get the results, and then you could do whatever you needed with it.
This is super-rudimentary explanation but there is a lot going on with what you're trying to do. My recommendation would be to get really familiar with calling API's on the web (you could use something like https://developer.forecast.io/ to get familiar with working with JSON and web requests) and then when you're feeling comfortable with all of that you could looking into working on the server portion. I don't know what your comfort level is with all of this but a lot of people focus on just one or two of these area's and not the entire stack. It can get overwhelming rather quickly. I haven't even talked about security, authentication, performance, etc... :D
Hope this helps!
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm aware of the differences between GET and POST (security and caching, in particular). Additionally, when I search this question using Google, I'm only greeted by results telling me how to hack site search in Google Analytics for POST-based engines. I already know how to do that.
What I'm wondering is why employ a POST-based search engine in the first place? What are the salient advantages? I can't imagine why site search queries would need to be secure. So maybe it has something to do with caching?
Thanks so much in advance to anyone who can shed light on this.
No real "answer" to this one - it's entirely up to the site owners choice and/or the options the software they use on their website.
I would however say that there are very valid reasons for search terms to be secure. If you are searching for personal private medical conditions for example, or perhaps your own sexual preferences that you'd prefer not to be widely known. And then there's search terms used in more restrictive countries than you're obviously used to where having a history of those search terms on your computer could get you in very serious trouble.
Google has long restricted search terms from being passed on to the next website in the referrer field for just the reasons.
Advantages of a GET based search page:
Easy to copy and paste link for someone else.
Adds to your web history.
Allows search engine to be implemented in client side (e.g. like Google Custom Search Engine uses with a JavaScript call to Google's main search engine rather than a complicated server side search engine implementation).
Advantages of POST based search pages are mostly to do with security:
Cannot be accidentally shared by copying and pasting URL.
Does not add search terms to web history
Cannot leak search terms in referrer fields for sites you click on. This takes extra effort to do with a GET request (like Google has done) but is default with POST requests.
This question already has answers here:
Best way to save data on the iPhone
(7 answers)
Closed 9 years ago.
I want to start an iPhone app for an E-learning recommendation system which does the following:
Let the user register or log in the app.
After logging in the app ask the user questions.
My question:
What is the best way to manage users to be able to log/register and save/retrieve user questions and answers?
I feel like I've answered this question many times before, but the alleged duplicate recommends using NSUserDefaults and I think that's poor advice for saving the data that your app manages. (The dupe is from back in 2008, BTW; the iOS landscape was somewhat different back then, but even so I still don't think the most popular answer gives very good advice.)
Since you're looking at having your users log in, there may be a server that they're logging into. If so, saving the data on the server is the right thing to do. Exactly how that work will depend on your infrastructure, but you'll probably GET and POST data to a web server using HTTP. There's a LOT of information on the net about how to go about that (lack of research is probably why you're getting down votes), but you'll either use NSURLConnection and NSURLRequest directly, or you'll use a third party library like AFNetworking that makes it even easier to access a web server.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
This is a very general and open-topic question. So yesterday we decided we would like to create an iOS app based off our website that is currently being built with Django. Now, Django, like RoR, is suppose to be transparent to the UI; it shouldn't care what UI the user is using. (Proper MVC).
If I look at some of our code for example, here is how we add an equipment into our system:
#login_required
def add(request):
r_user = request.user.userprofile
form = EquipmentFormAdd(request.POST or None, c_id=r_user.company_id, error_class=DivErrorList)
if form.is_valid():
equipment = form.save(commit=False)
equipment.company_id = r_user.company_id
equipment.added_by_id = request.user.id
default_file_path = EquipmentPicture.get_default_file_path()
url_bucket = r_user.company.s3_bucket.name + default_file_path
cell = form.cleaned_data['cell']
equipment.cell_order = cell.equipment_set.count() + 1
equipment_picture = EquipmentPicture.objects.create(
file=EquipmentPicture.get_default_file_path(),
slug=EquipmentPicture.get_default_slug(),
bucket_name=r_user.company.s3_bucket.name,
bucket=r_user.company.s3_bucket, added_by=request.user,
company=r_user.company, url_with_bucket=url_bucket)
equipment.picture = equipment_picture
equipment.save()
return redirect('equipment_index')
return render(request, 'equipment/add.html', {'equipment_form': form, 'company_id': r_user.company_id})
If I look at this, I see that we are rendering straight-away a template and passing it data. This would't work in iOS.
Few questions:
I see a lot of people creating REST APIs. I don't really see the point of doing that if we can just create HTTPResponses with Django. If we were to use something like TastyPie, we wouldn't be able to just create an equipment (like we do right now) with a POST Statement as if you look at our current add function a lot of stuff is done within that function and TastyPie wouldn't be able to call that.
My main question is should we have a REST API running as well as the normal Django server for both the Web and iOS platform, or just have the same functions, with different entry points and renderings according to it?
When do you create a REST API? A lot of our functions when creating and getting data wouldn't work right now with just standard POST and GET calls. Is that bad?
I am kind of confused... sorry for the long question and thanks again!
A REST API is not something different to GETs and POSTs. It's just using them for data instead of presentation. You output JSON or XML instead of markup code. The API consumer then builds the needed user interface to the data.
The real point of a REST API is to take profit of all the tools that HTTP already offers, instead of inventing another layer of encapsulation (like SOAP)
For instance, to indicate the result (success or not) of some action, use the status code. To indicate an action to perform, typically use the verb (get, post, put, delete, head, options). Other request or response metadata will go into appropriate http headers.
This way data is simpler, caching is easier, and integration is easy as pie.
Also, with a good REST API, you could even build a website that uses some JavaScript framework (eg backbonejs) to build UI from data consumed from the API.
UPDATE
So, given the current status of REST things in Django, and having some experience producing and consuming APIs, I'd tell you to build either:
A RESTful API alongside your web, using the same controllers you use for the website if possible. The same web is in fact RESTful, the only difference is that it is not an API. I have tried in some projects to use several libraries to build an API, but always ended up producing my own code for it. Sometime it's easier that way. All client applications (iOS, android, whatever) will use your API, so you can decouple it completely.
If you don't feel comfortable building all the API by yourself, maybe piston can be a valid alternative to tastypie.
ONLY a RESTful API, and rebuild your site using client-side technologies. Why keeping your (few) servers busy producing HTML, when your (many) customers'/users' browsers can do the same work and you don't pay the electricity bill?
In any case a RESTful API will help you to get the data structure of your application well-organized.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Our in-house built CMS system has the ability to have descriptive url (Descriptive URLs vs. Basic URLs) versus basic urls (http://test.com/index.php?id=34234) We want to know other than giving a little more feedback to crawlers out there, if will mean something else.
Do having this descriptive urls bring us other benefits?
Should we limit the size of the URL to certain amount of words?
Thanks for you time.
There are several benefits to descriptive URIs:
It can help with search engine optimization if they include relevant keywords
URIs without query parameters can be cached for GET requests (query parameters prevent caching)
They are descriptive to the user, so their location within the site is clearer to them. This is helpful if they save the link too, or give it to a friend. The web benefits from semantic content, and this is just another way to provide it.
They may also be able to modify the URI directly, though this is a potential downside too.
It is generally good to keep the length under 256 characters due to legacy constraints, but today, the actual limit in practice is not well defined.
Descriptive URLS feature major SEO benefits, as search engines weigh the contents of the URL heavily.
There are many benefits to it. Not only do they work better for SEO, but they are often times hackable for your end-users.
https://stackoverflow.com/questions/tagged/php
That tells me pretty straight forward that I'm going to find questions tagged as "PHP." Without knowing any special rules, I could guess how to find the jQuery questions.
You will run into a limit on the amount of space you can squeeze into a url, but limit the urls to core-terms (like titles to an article, etc) and you'll be fine.
One suggestion is to use these types of urls, but have a fall-back plan. For instance, the url to this question is:
Is having a descriptive URL needed to be a web 2.0 website?
The first parameter is 1347835, which is the question id. The second parameter is the question title. The title here is completely optional. It's not needed to access this page, but when you use it in links it increases the SEO for this page.
If you were to require the title be exact, that may cause more problems than you want. Make the SEO-content like this optional for loading the content itself. SO only requires the question-id, as I stated before.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What's the best way to make a website localized to multi languages?
I'm working on a website, and our manager wants it to be like:
http://www.website.com - default to english
http://fr.website.com - french
http://de.website.com - german
He says it's good for SEO, some developers wants to make it based on cookie and user's accept-language, so the url would always be http://website.com but content would be based on cookie/accept-language.
What you think?
thanks!
This article appears to have a good guide to your question: http://www.antezeta.com/blog/domains-seo/
Essentially, they recommend localizing by TLD most, followed by Subdomain, followed by directories
Cookies are a bad idea because Google will not be able to index your localized content.
This might be late answer but I will give you anyway (my hope is it will benefit others).
Should http://www.example.com/ default to English?
No. You should always detect User's preferred language. That is, web browser will give you AcceptLanguage header with languages that end user is able to understand. If it happens that the most preferred one is not the one that your web site/web application supports, you should try to fall back to next language from AcceptLanguage. Only when nothing fits, you should fall back to your default language (usually English, United States).
Should we used languages as part of domain?
It seems a good idea. When you detected the language, you might want to redirect user to appropriate page. It could be something like http://french.example.com/, http://german.example.com/ or http://www.example.com/index.html?lang=fr.
It is good to have such mechanism implemented - in this case one could actually bookmark correct language. Of course, if somebody navigates to your web site with language as a parameter, you will skip detection as it is pointless at this time.
To sum up:
You may should detect language that web browser serves you and appear as you have multiple web sites (one language each). That is how user might choose which one to bookmark. And of course web search engines will probably index the contents separately, but they would rather look for robots.txt, so... Either way it is good to appear as several language-specific web sites.
I once heard a teacher of mine say that when he does this, he simple makes php files called "eng.php" "fr.php" and so on...
In these files are associative arrays. The key's are always the same but the translation is different.
Then you need only require the correct language file at the top of you PHP files and if you parse the keys, it'll always be in the correct language.
Most open-sourced approaches to localization and globalization involve a lot of developer overhead and complexity in maintenance as copy and code become more complex.
My current company Localize.js solves this complex pain point seamlessly, by tracking website phrase changes, automated ordering of translations, as well as dynamic rendering of languages for you.
https://localizejs.com/
Feel free to email me # johnny#localizejs.com, if you have any questions