I will soon make a mobile application. For the front-end I will use React native and for the back-end I want to make an API but I don't know which technology to use, Django REST API, express js?
My problem is with regard to the videos to store, which technology is going to be the most suitable for storing them?
So, what technology would you use to create an API that can store videos properly and that will be called by react native?
There is no simple answer to a question like this. It all depends on your expectations, experience, resources, time, etc. It is also a very subjective question because most developers have their own preferences about these solutions. The truth is that you can build a solution in A LOT of different ways. Besides the JS frameworks you suggest, popular choices are .NET, PHP, C#, Ruby, Java and Python... and much more!
Besides the backend / API, you will also need a server for hosting your API and maybe another type of server for storage.
If you want to build everything yourself, take a look at the services provided by AWS, Azure or DigitalOcean. If you have limited experience building backends and want to save time, take a look at Google Firebase or Heroku.
The last two are plug-and-play solutions for expecially mobile apps like the one you are describing.
Check it all out and make your own opinion!
Good luck with your project! :-)
Related
I want to do my final year project on augmented reality geo-localization,
Please tell me, from where to start ?
what technology to learn ?
what are recruitments to development this kind of application ?
If you want to perform Geo-Localisation and use GPS, I wouldn't recommend using Unity. It's arbitrary coordinate system can be a bit confusing and difficult to make an app using GPS that's reliable enough.
For Augmented Reality, you can't use anything like Oculus Rift or Google Cardboard, because those are Virtual Reality headsets and have no way of allowing the user to see the real world. Augmented Reality peripherals are things like Microsoft Hololens or Google Glass, neither of which are commercially available but there are cheap knock offs that are. AR can also of course be used on any mobile device, since they all have a camera built-in and chips powerful enough to process all the tracking data.
As for making an actual app, the best thing you can do is have a go. Analyse your market, see where the gaps are. If you want to make an app for a specific OS that isn't cross-platform, I would recommend learning some Objbective-C (for iOS) or Java (for Android), if you don't know any already.
For cross-platform, I would say something like Xamarin would be useful for making an app on both the major OSes, it was recently made free by Microsoft and you can essentially make one app in C# that works across all devices.
For the Augmented Reality itself, there are frameworks out there that can be used for your purposes. Things like Kudan, Vuforia, Wikitude, etc. Some of them offer free versions of their software. You can use these to deal with all the tracking and projection side of things so you don't have to go about creating your own AR engine.
The best thing to do is probably to sit down for a few minutes, or hours, and think about what you're going to do. Figure out what you want the end result to look like, then work backwards and think about the best way to achieve that goal. Eventually you will arrive at the language and engine you want to use to make your life as easy as possible and then you can get started learning from tutorials online and getting your app out into the world.
you can check my tutorial about geo-based augmented reality solution on Android: https://www.netguru.co/blog/augmented-reality-mobile-android
I have presented there the basics and how to start with simple implementation.
Well a good starting point would be to ask yourself few questions:
What type of devices, you plan to work on(oculus rift, google cardboard, Microsoft Hololens, web etc)?
Augmented Reality is achievable in both Web-Context and Application-context. Which route do you want to go for?
Depending on these questions, if you choose to do a normal application based on a device, then depending on the device(Oculus Rift, Google Cardboard, Microsoft Hololens), you would need to grab their specific developer kits and learn how to develop apps using the documentation. For Oculus rift and Microsoft Hololens, you would need the respective Headsets inorder to make an app in that, but If it comes to google cardboard, all you need is you mobile phone with a good processing power.
There is another way to work on augmented reality applications, that is by doing a Web Application using some amazing javascript libraries like Awe.js, Three.js and JSARToolkit.
You can google about them and find out more.
One of the more accessible ways to learn Augmented reality is Project Tango.
Devices are around $500 last I checked and you can use a free version of Unity + Project Tango's free plugin:
https://developers.google.com/project-tango/
Which ever hardware you pick I'd recommend checking out Unity3D as it seems to be the platform of choice for AR/VR at the moment. There are other options... this just provides the most flexibility based on all of the platforms it supports.
Side note: I have no affiliation with Project Tango and am in fact working on another platform... but it isn't as accessible at the moment.
I've been trying to develop a cross platform mobile app, very simple one (DB driven), so I had to chose between PhoneGap, Appcelerator and Rhomobile.
I'm a big fan of Ruby and ROR, so using the same MVC structure and Ruby syntax is a big advantage for me.
Anyways I would like to ask few questions here if any of you guys used it already as it's a very risky decision specially that it is the least known framework among the mentioned above.
Do you know any solid smartphone App that used Rhomobile? this could give it more credibility. I don't wanna invest much time developing the solution then to get refused from apple appstore for some reason or to face any major problem in the production.
Did you notice any performance issues? specially with the UI? as it is not a purely native application (unlike RubyMotion or Objective-C) ?
Do you have any idea of the pricing? for commercial uses? is there any fees or is it totally free app?
Thanks in advance
I have been in the trend of developing RhoMobile applications since more than 2 years. In my opinion, i found this more powerful and stable than other frameworks.
Since you are a ROR/Ruby developer, it's will be lightning fast speed for you to catch the flow. you will not believe that most of the concepts of ROR are available in this framework.
Regarding your queries,
Do you know any solid smartphone App that used Rhomobile? this could give it more credibility. I don't wanna invest much time developing the solution then to get refused from apple appstore for some reason or to face any major problem in the production.
You will find no issue while deploying the app to stores if you just simply follow the basic flow as they have on there documentation. Although it's not as easy to check for the apps based upon the technology used, but this link may help you.
https://developer.motorolasolutions.com/thread/1736.
Did you notice any performance issues? specially with the UI? as it is not a purely native application (unlike RubyMotion or Objective-C) ?
All the Hybrid apps usually have a layer between you coding and the native api, which will any how take some few amount of reaction time, be it Rhomobile, Rhonegap or others.
But as per my experience, same performance degradation have been marked by me, than the native one for all the frameworks.
Do you have any idea of the pricing? for commercial uses? is there any fees or is it totally free app?
If you want to use only RhoMobile. Its free. But if you want to use some advance modules and some core modules, you need to have the RhoElement license for this, which is basically a paid one.
Hope these points help you deciding you best framework.
I am currently developing a very simple web service and thought I could write an API for that so when I decide to expand it on new platforms I would only have to code the parser application. That said, the API isn't meant for other developers but me, but I won't restrict access to it so anyone can build on that.
Then I thought I could even run the website itself through this API for various reasons like lower bandwidth consumption (HTML generated in browser) and client-side caching. Being AJAX heavy seemed like an even bigger reason to.
The layout looks like this:
Server (database, programming logic)
|
API (handles user reads/writes)
|
Client application (the website, browser extensions, desktop app, mobile apps)
|
Client cache (further reduces server reads)
After the introduction here are my questions:
Is this good use of API
Is it a good idea to run the whole website through the API
What choices for safe authentication do I have, using the API (and for some reason I prefer not to use HTTPS)
EDIT
Additional questions:
Any alternative approaches I haven't considered
What are some potential issues I haven't accounted for that may arise using this approach
First things first.
Asking if a design (or in fact anything) is "good" depends on how you define "goodness". Typical criteria are performance, maintainability, scalability, testability, reusability etc. It would help if you could add some of that context.
Having said that...
Is this good use of API
It's usually a good idea to separate out your business logic from your presentation logic and your data persistence logic. Your design does that, and therefore I'd be happy to call it "good". You might look at a formal design pattern to do this - Model View Controller is probably the current default, esp. for web applications.
Is it a good idea to run the whole website through the API
Well, that depends on the application. It's totally possible to write an application entirely in Javascript/Ajax, but there are browser compatibility issues (esp. for older browsers), and you have to build support for things users commonly expect from web applications, like deep links and search engine friendliness. If you have a well-factored API, you can do some of the page generation on the server, if that makes it easier.
What choices for safe authentication do I have, using the API (and for some reason I prefer not to use HTTPS)
Tricky one - with this kind of app, you have to distinguish between authenticating the user, and authenticating the application. For the former, OpenID or OAuth are probably the dominant solutions; for the latter, have a look at how Google requires you to sign up to use their Maps API.
In most web applications, HTTPS is not used for authentication (proving the current user is who they say they are), but for encryption. The two are related, but by no means equivalent...
Any alternative approaches I haven't considered
Maybe this fits more under question 5 - but in my experience, API design is a rather esoteric skill - it's hard for an API designer to be able to predict exactly what the client of the API is going to need. I would seriously consider writing the application without an API for your first client platform, and factor out the API later - that way, you build only what you need in the first release.
What are some potential issues I haven't accounted for that may arise using this approach
Versioning is a big deal with APIs - once you've created an interface, you can almost never change it, especially with multiple clients that you don't control. I'd build versioning in as a first class concept - with RESTful APIs, you can do this as part of the URL.
Is this good use of API
Depends on what you will do with that application.
Is it a good idea to run the whole website through the API
no, so your site will be accessible only through your application. this way This implementation prevents compatibility with other browsers
What choices for safe authentication do I have, using the API (and for some reason I prefer not to use HTTPS)
You can use omniauth
Any alternative approaches I haven't considered
create both frontends, one in your application and other in common browsers
What are some potential issues I haven't accounted for that may arise using this approach
I don't now your idea, but I can't see major danger.
Most of the applications these days provide an API...be it twitter,gmail,fb and millions others.
I understand API Design can not be explained in just an answer but I would like some suggestions on how to get started with API design. Maybe some tutorial/book that makes an application and has some chapters on how to go about providing API's for it. I'm mostly a java developer (learning Groovy) but am open to other languages also, if it is easier to get started with API design in that language.
As a side note, before I was curious about the difference between an API and a webservice. But now as I understand it, webservice is just a form of an API
I don't have any great resources however, I want to stress how correct that API is Application Programing Interface, and is simply a mechanism for how you expose your application to be consumed by others. Be it from script, web service (soap or rest), Win32 API Style Calls....
About 10 years ago when we talked API it seemed like everyone felt like all APIs were like Win32, and that was it. One of the more interesting I've worked on was an API with a PICK based Management System. In this case we wrote an XML processor in PICK and were screen scraping XML back and forth over a telnet session.
The first thing you need to decide, is how do you want to expose your data. Are you going to expose over the web? Or is your application a desktop application? How I would structure an API for cross machine communication tends to be different then if the API is running in a single process or even on a single machine.
I would also start by writting a test client, You have to understand how your API will be used first and try to make it as simple as possible. If you dive right in with the implementation you might loose perspective and make assumptions that a client developer might not.
We're about to build a Blackberry application but would love some input on whether to implement using J2ME (MIDlet based) or Blackberry native (UIApplication).
I understand some of the tradeoffs. J2ME will be more flexible if we want to port the app to other devices. RIM has better support for Blackberry native.
The place I'm still lacking information, though, is on the UI side. We want to build an app that has a great user experience, and one that looks like other apps BB users are accustomed to. Can we do this if we go the J2ME route?
Apologies for the somewhat subjective and less technical nature of the question.
I've tried it both ways - building a pure MIDP app to run on BlackBerry and non-BLackBerry platforms and building a separate BlackBerry app (often using much of the same business-logic and networking code as the MIDP app). Definitely go the BlackBerry native route.
It's all about the BB UI classes. They'll give you the ability to (among other things) respond to the different type of menu events (trackball and menu key), respond to BB specific key codes, if you're interested in the Storm take advantage of the orientation sensor and touch support. Plus they're a much richer set of UI elements to work with. You can build up a lot (but not all) of what they do in pure MIDP, but end up customizing so much of it for each platform that you won't save anything in the end. Starting with the BB UI and customizing saves a lot of time and effort.
Even in gaming applications, or for applications where you're custom drawing all your components, you have better access to the BlackBerry graphics APIs and get better performance going the BlackBerry native app route. And you still have better detail about input events.
Finally there are some nice lifecycle things you can do with BlackBerry native apps, like pushing to the background, or auto-running on system startup that you can't do with MIDlets, which may be of interest depending on your application.
Also think about market - if you're planning on supporting BlackBerry right away, and then maybe other MIDP platforms down the road, it's usually a better plan to execute the best you can on your initial platform. There probably won't be much of a reason to port to MIDP later if you don't succeed on BlackBerry first.
BlackBerry is a very difficult platform to program for. I went the native route and found it to be very poorly documented and overall just a miserable design to work with. I did feel it to be necessary because you will lose the ability for certain features (scroll wheel?) if you go the J2ME route. It's a tradeoff and you'll have to choose the one that fits better for your specific need.
I have been working with J2ME since 2002 when the Nextel/Motorola phones were in the forefront of J2ME functionality. I deal primarily with non-gaming applications. Today with J2ME evolving and more phones conforming to the JSRs my application continues to port smoothly. This year I finally got around to moving it to a Blackberry device. Two days later my application is fully functional on a Blackberry. The application is purely generic J2ME and uses many of the JSRs (location, bluetooth, xml, etc ). A strong UI design helps. I extended some of my UI classes to support the QWERTY/SureType keypads. I have used a variety of native applications found on Blackberry devices (not games) and I have yet to justify any reason to venture off to the RIM API to see what I would benefit. The arguments expressed above by other fellow programmers further prove that there is very little to gain unless you are purely devoted to a Blackberry device platform.
Without knowing the scope of your application, meaning which devices you will target, another thing that you will need to take into consideration is the ever expanding differences in input for each BlackBerry model. Some devices, like the Curve and the Bold, are standard QWERTY pads where other devices, like the PEARL, have SureType pads. And then there's the Storm which supports both depending on the orientation of the screen. Also, the SureType pad needs to be used as a standard number pad if the user has it set that way. The native APIs have support for all of this where you won't have that luxury with standard MIDP.
Another tip when designing your user experience, I would get my hands on a few different BlackBerry models and try out some of the apps that come standard as there are a lot of shortcuts that users become accustomed to using that you might not even realize exist. For instance, the SPACE bar pages down. This is huge for reading docs, however I have a third party RSS feed reader that does not have this functionality and I always attempt to use it first before remembering that it doesn't exist in this app. That kind of small detail can make a huge difference to BlackBerry users.
There is a way in between: You could use J2ME-Polish and code natively in J2ME. Polish will add the look and feel of a native BlackBerry app to some extent. That has the advantage of porting your app to other J2ME phones and not be limited to BlackBerry.
I agree with Anthony, I'd go with the BlackBerry specific APIs for BlackBerry apps. J2ME is just not portable, and BlackBerry has a lot better support for their proprietary APIs.
From my experience: stick with the native BlackBerry UiApplication. It is the best for BlackBerry and provides the best user experience for BlackBerry users. You can't copy that with J2ME easily.
J2ME is simple to develop. And, BlackBerry API has many feature also you can use restricted class with simple signing. BlackBerry sells their sign certificate and it is cheap. 20$. You can use this certificate to sign and use all restricted class. In J2ME, sometimes you must use more than one certificate, even you can not use all phone capabilities. So, my suggestion is, use BlackBerry native API and some J2ME Wrapper Codes. So that, you can code easly as J2ME and can use all capabilities of BlackBerry native API.