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.
Related
Ok this is more informative question than on a coding question. However this is a two part question.
When building the flavors for example an MP3 player.. you would have free and premium. I started designing a flavor app of an MP3 player to start learning Flavors and Build variants.
What i am trying to understand is when building the flavor is all of the design for the flavors built in Project then each flavor is specific. Premium features for Premium and free features for free. I understand that.
However what i am not understanding about the design is when i design my login with firebase how do i call the flavor thats appropriate. For testing purposes lets forget firebase. Here is an example:
MainActivity has two buttons. One will point to the free and the other paid. So if i press the free button do provide an intent that points to the flavor as this:
val i = Intent(......buildConfig.flavors.free)
Or would i place the package name in where the buildConfig would go. This is not actual code this is just an example.
Keep in mind i have never built a flavored app. So this is a learning point for me.
My original idea was have a free version as default with an in app purchase. You use the in app purchase and if the purchase is successful then the premium would take effect.. the only differences in the actual deaign would be those premium features are enabled.
So the first question would be: Is there really a difference between same design flavors versus in app purchases?
The second question is: when building a flavor app with the same design. Do you have to use flavors, example Free/paid, if the design never changes.
Like i said this is a learning process and all my apps on google play is just a flavorless app with adMob banner ad. So i an wanting to venture out to a more simple aspect than having two apps on google play one app for the free and another app for premium.
I think it would be easier to do flavors. However i have never done a flavored app and all the research i have done does not give clear instructions. They all stop after the gradel file implementation.
So any direction would help with is flavors a must or is it more headache to deal with in my case for learning purposes versus real world application.
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.
Anyone knows of a tool like GameSalad for PC in which you don't have to write scripts or anything but just use the existing behaviors and events to create custom game logic?
Thanks
If you are looking for a cross platform game constructor you might want to try Flowlab, which runs in a web browser.
Construct from Scirra is a free, open-source, drag and drop, game engine. There is however talk of them making a paid version of Construct in the future.
I've only used Construct once, so I don't know that much about it, but i do know a lot about GameMaker.
As long as your not trying to do something complicated like a 3D or MMO game, (both of which GameMaker supports, but with major limitarions) I would recommend you use it, especially if your just starting out. GameMaker is one of the easiest if not the easiest programming language to learn. It also teaches good programming skills. As I mentioned before GameMaker uses drag and drop so you can easily transition from the D&D to the progeamming aspect of GameMaker.
As mentioned in the above posts RPG Maker is another popular tool , but it's limited to RPG games, and doesn't allow you to easily transition to an actual programming language. It's also very restrictive in what you can do.
When you feel like getting into some more advanced gaming engines, Blender is a great tool to use for creating 3D games. It can also be used to create 3D modules and has the ability to create animated movies.
I've never used PyGames before, but Python is a easy language to learn, and would probably be the best way to transition from a D&D program to a programming language.
*GameMaker can be extended in functionality with DLLs and Blender can be extended with Python.
So to summarize, GameMaker is a great tool for creating Games. RPG Maker and Construct are other possibilities, but from my view there not as good as GameMaker. when your ready to get out of Drag&Drop gaming engines Blender, PyGames, and GML(Game Maker Language - the advanced part of the GameMaker product) are all great resources.
PlayBits has an interface similar to GameSalad and makes games for Windows Phone 7, using your PC. Here's the link: http://www.playbits.com/?page_id=171
RPG maker here you can find it is a light weight game engine but if you are clever you can make really good apps
In terms of game development for iOS and Mobile development using the Windows platforms you might want to have a look at these two:
http://www.giderosmobile.com
and
http://www.stencyl.com/
Although I haven't, yet, used the Gideros solution, it's targeted specifically for Mobile platform development and has what looks to be a tidy UI with code folding and syntax coloring if you're comfortable with a traditional coding approach.
Stencyl is an interesting product, it sits beyond the capabilities of Gamesalad and uses a blocks metaphor for programming which works well.
Personally, I wouldn't use any tool that has a single platform for output, which is why I stopped using Gamemaker (I'm aware it now has a Macintosh client, but the quality of the application has been terrible and their player isn't much good either.)
If you're looking for GameSalad for Windows you might want to check out our HTML5 game engine Construct 2 which functions in a similar way.
It's also got an event based system with no programming required, and there's an extensive free edition available for you to try out as well.
You can use Yoyo Game's GameMaker:Studio also.
GameMaker is one such tool.
There is also The 3d Gamemaker, by the same people who make other rapid-game-development tools like DarkBasic.
The recent article of steve jobs link
made me think about the future of flash. I'm learning actionscript 3.0 in my studies but is it the right decision still to go for it? I was pretty sure that I will be able to build application in as3 for iphones/ipads in the near future. It seems to me, while I would stay with flash, the market will be polarized by apple and adobe and you will always work double for both clientele, or just lose half of them.
Which decision would you take as a designer, if you were still at university and you intend to become a freelancer?
This question has been around a lot of times. For my opinion on flash's future please look at this answer: Should I Abandon Adobe Flash for HTML5 and <canvas>?
If you are a designer, you will probably actually feel good working with Adobe's Creative Suite, including Flash CS3/CS4/CS5. CS5 will be able to export HTML5 in the near future: http://www.9to5mac.com/Flash-html5-canvas-35409730 . You shouldn't be too worried. OTOH you should consider, that whatever CS5 exports is likely to perform poorer in HTML5, than on flash player.
From my perspective as a developer, I think there is no harm in learning any language, altough ActionScript 3 is relatively boring and easy to grasp. However this makes it a good language to learn programming, including many best practices. The most important things you learn as a programmer transcend languages. The more languages you try to really fully understand and exploit, the better you become by understanding the approaches they promote.
My personal advice to web developers is to have a look at Haxe. It is a much more powerful, elegant and expressive language than ActionScript and it allows you to target many platforms. Enough to build a whole web app on 'classic' platforms with only one language. Haxe's C++ backend allows building native iPhone apps using an SDL based port of the flash player API, although currently it's not very clear whether Apple's policy will allow distribution. Nonetheless it is an open source language with an enthusiastic community, that moves really fast and adapts to changes rapidly (e.g. unlike ActionScript Haxe can leverage flash player 10's alchemy opcodes for fast memory access) making you as a developer independant.
edit: I have personally dropped any plans of targetting the platform until Apple is willing to ease its very restictive policies, since I find this kind of behaviour intollerable. Nonetheless, I think Objective-C is a great and inspiring language, so you may actually wanna have a look at it.
I think that reports of the death of flash have been greatly exaggerated. Flash has always been "the bad guy" - self-proclaimed experts have always loudly declared that Flash sucks and is on its way out, but oddly enough I've never had any trouble finding lots of Flash work. There are things that you can do quickly and easily in Flash that are either much harder or flat-out impossible without it. It's an amazing tool and it's going to be in use at least in some capacity for the foreseeable future.
That said, even if Flash on the web goes the way of the dodo in two years (which won't happen) it's still a valuable tool. It's a wonderful way to learn Object Oriented Programming, and its uses go far beyond shiny websites. You can use something like Flash Builder in Eclipse to get accustomed to working in a code-oriented IDE, you can build AIR apps to deploy across platforms, you will soon be able to publish saleable apps to every major phone including the iPhone, etc. I've been having a lot of fun with it lately getting it to work with Arduino - it's just a hobby project but I'm trying to build a little helicopter that I can control from an AIR app. I'd be curious to see someone do that in HTML5. ;)
Flash is amazingly powerful - your abilities are in many respects limited only by your imagination and willingness to figure out how to make it work. It's really bizarre to read all of this stuff about how (some) browsers can now play (certain types of) video one their own, ergo Flash is Dead. How unimaginative. :)
This is a tough call. Flash is a fairly dominant technology at this point when it comes to media-intensive web sites. Flash is also very popular for delivering mini-games. I do think that Flash video, which is currently also dominant, will gradually be replaced by HTML5 technologies. I'm not so sure that Flash can be replaced easily when it comes to those media-intensive sites. There is a large number of very talented people comfortable with Flash that might be reluctant to adopt other technologies. I would probably hedge my bets and get comfortable with Javascript and other HTML5 technologies.
Apple vs. Adobe controversy reveals two opposite views of mobile computing.
Apple wants that its developers make the best of its devices by excluding middleware. The aim is to deliver the best possible user experience.
Adobe wants that its developers publish their work on as many platforms as possible. The aim is to reach the widest audience.
Nobody knows which view will win in the future. The mobile war is just beginning...
I think it depends on how far into the future you want to look, and what you think is most important. Flash on the desktop will not die for a long time, if ever. If that is good enough, keep going with where you're going. If not using flash on iPhone/iPad is a deal breaker, you only really have two choices - Objective-C or HTML5.
HTML5 is definitely gaining momentum, but it can't be used directly in all browsers yet, and likely for a while. However, in the mobile space, there is pretty excellent support in the major smart phones.
There isn't a single platform/technology/language that can hit everything. If I were going to bet money on the future, though, I would say HTML5 is going to win for the most reach across platforms. And given it is on the rise, I would bet that in the next few years, there will be a lot of demand for good developers in this area, but don't expect the path to be fully paved for you. You'll have to get your hands a little dirty. If you're looking for a decent editor, I use Netbeans, but I also do Java development, so that makes sense for me. Search around, though, and you'll probably find a decent set of tools that work well for you. It is a very active space.
As far as I'm concerned, Actionscript is a pretty good language to learn OOP. Javascript is a bit shit. Eitherway, I would expect you'd learn a certain set of (frontend/2d graphics) skills which will come in handy regardless of the vehicle you'll eventually use to deploy your work.
Personally, I like the flexscript language used by Flash, it's more structured and object oriented than Javascript. Also it has real inheritance, not the prototype based crap, and compiles to bytecode. For the artist, Flash is easier to use in many ways due to the available tools.
I do hope for better integration into browsers. The current flash plugin is clunky and causes crashes for many users, also the plugin system makes it integrate badly into the flow of pages.
With HTML5, I think the browser plugin idiom is dying in general. Everything from video playback to fancy vector animations can be done with just HTML + Javascript. Even a standard for 3D graphics in webpages is on the way (O3D).
Also I wonder how Adobe will cope with the current explosion of platforms/operating sytems/browsers, especially in the mobile realm. At the moment, the Flash support for systems except for Windows on PC isn't much good.
Just as projects like SVGWeb brings SVG capabilities to browsers that don't have native SVG, I would expect that if/when HTML5 gains traction against Flash there will be conversion capabilities from existing Flash to browsers without Flash. In fact, Adobe already has a conversion from Flash to iPhone using Flash Professional CS5. IMHO, there's too much Flash content in the wild for this not to happen eventually, and there are too many people for which Actionscript is their primary (or only) language for some conversion not to happen.
Career-wise, the clear long-term trend is away from Flash, and I agree with Tom that hedging your bets is wise. However, HTML5 is still fairly new, and you might do yourself a disservice to ignore Flash at this point. With conversion technologies, a Flash skillset will likely be usable for at least several years.
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.