Related
First off, greetings everyone and thank you for your interest in my question.
I'm currently working at a mobile startup. Our product is a communication app for Android, iOS and BlackBerry devices and we're looking to expand onto some Nokia platforms.
I don't know a lot about Symbian details as I've never actually programmed in the platform before but this is all of the information I was able to gather.
The platforms to support are Symbian S60, Symbian^3 / Symbian "Anna", Maemo + Meego.
In order to accomplish this, there's several tools at our disposal but we're not sure which ones to use.
Nokia Qt appears to be unsupported on Symbian S40 devices (we seem to be stuck with J2ME) and Symbian S60 devices pre-3rd Edition Feature Pack 1
On Symbian's C++ we can't rely on C++'s STL. This means that we can either create two versions of the same software or create our own STL that's compatible with Symbian (I'd like to avoid that).
Approach
Among the team the consensus seems to be to split this into two logical chunks:
Core business logic + libraries in C++
Device specific UI branches using Qt or native UI tools
With all this information in mind, I ask:
What is the general approach for this problem? Is there any considerable flaws with the one mentioned, namely incompatibility or inconsistencies with Qt on older platforms?
What pitfalls should we avoid to ensure compatibility and performance of the app across all Nokia devices listed?
Is there a way to get around Symbian's C++ limitation of the STL? Can we bundle the Qt sources somehow?
Suggestions and other approaches are welcome. Thank you for all your feedback.
You should consider that Symbian is a dying platform, so I would not invest huge development effort into a Symbian application. And even more so I would not use Symbian C++. Qt is a promising platform but Nokia/Microsoft announced that there will be no Qt port for Windows phone (which might be interesting for you).
Maybe you should support Nokia devices only by Java ME because Symbian has big market share but the most devices are not smartphones where you can run a Qt app.
Your approach sounds very idealized, but I am not sure if you can use the C++ libraries you mentioned for the business logic from Java ME. Is that possible?
There are STL implementations that are possible to use on Symbian.
I was once part of a team hat used a C++ core (with STL) on Symbian devices ranging from S60v1 to S60v5 as well as UIQ, S80 and S90. The same core was also used on windows mobile.
We used STLPort for the STL implementation, but I have been unable to find that specific version again. I do believe there are other Symbian STL implementations out there.
On the other hand S60 device have a very competent J2ME runtime, so if you have to develop a J2ME app for S40 devices you might as well use it on S60 as well.
I am not more experiences as you but according to me Qt is good for Application development.Write code once to target multiple platforms
Qt allows you to write advanced applications and UIs once, and deploy them across desktop and embedded operating systems without rewriting the source code saving time and development cost.
Thanks
2 questions:
Can someone tell me if unmanaged c++ code will
be supported in future versions of Phone 7 OS for all developers?
What are MS reasons for not
supporting unmanaged c++ code?
This answer is purely speculative, but I feel that most others who have answered this question miss the point by a long shot. Let's for a moment assume that this is not a vindictive decision by Microsoft, but instead actually a very well thought out engineering decision that has absolutely nothing to do with content restrictions or otherwise. Those issues are just a bonus for MS
Microsoft is entering into the mobile market, this time for real it seems. Pretty soon there will be tens of millions of Nokia phone being shipped using Windows Phone and whatever they get on top of that will just be gravy. Windows Phone though still hasn't really found its home.
In the next year or two, phones, tablets and laptops will finally start converging into a single device. People will carry their phone in their pockets, but that phone will also be the CPU unit of their PC. That means that by simply sitting near a wireless HDMI monitor and connecting a keyboard and mouse via wireless USB (or bluetooth if we're all unlucky), the user will have their entire PC with them at all times. Tablets will become just a battery powered touch screen which interfaces to the PC in your pocket.
So, all software written for Windows Phone should be able to run unmodified on a PC, a tablet and/or a phone. This is because there's a huge chance that the PC you're running will be either x86 or ARM based running Windows 8. When the PC is in your pocket, the user interface you'll see will be the Windows Phone GUI. When you're hooked up to a monitor, you'll see the ribbon interface. But the underlying OS will most likely be Windows 8, not the Windows CE that is currently used.
Based on all this, the only way Microsoft can insure that developers who invest in producing apps for the Windows Mobile market will not be screwed and that users of Windows Mobile devices won't be shorted when the newer platform comes around is to ensure there is a standard system for running apps on all these processors.
Even now, writing for Honeycomb is a nightmare since if you develop native code, you have to support both ARM and x86 and there's no real support mechanism for it. The only solution is to develop, package and ship two versions. Writing apps for iDevices are a little easier since there's no overlap. x86 on desktop, ARM on device. If you have to use native code on device, ARM is all you need. Even then, there is fat binary support on both device and desktop, so this won't be a problem except when optimizing.
In the end, the decision by Microsoft to stick strictly to .NET is probably a good one. Once they have a gazillion Nokia phones on the market and things have settled a bit, native code could be a real possibility.
These answers are for the application development perspective. OEMs can write native code today, as that's how they create drivers, but that's not open or available to most developers and therefore of no use to most.
For #1 Microsoft has made no announcements, so only Microsoft knows the answer and they're not saying.
For #2 it's all about code security and overall platfrom stability It's very tough to sandbox native code and they don't want your app being able to affect other apps or the platform itself. The general idea is that you should be using Silverlight or XNA for application development, so that's what they expose.
Windows phones will go nowhere with native support. Games and other more intensive apps are driving sales. Android was forced to blow the lid off of its NDK to support the games industry. As far as supporting multiple processors, etc., those of us doing this kind of work have been doing it for a long time, so its no problem. Already handling Intel and ARM without a problems with our systems.
EDIT, finally: for WP7 unmanaged code won't ever be supported, but in Windows Phone 8 - yes it will! They've just announced it. Native apps, C/C++, iOS/Android portability and code sharing, DirectX. You'll need Visual Studio 2012 and Windows 8 for WP8 development, though. Looks like VS2010 is not getting the requisite WinRT SDK.
The nongame UI, however, will still be XAML-based. Win32 API will not be supported. They're pushing a model with managed UI layer and a native middleware beneath it.
SDK will be available later this summer.
For the sake of posterity, here's the pre-06/20/2012 answer:
Microsoft probably can.
To ensure platform closeness, as a means for attaining stability and UI consistency. To enforce app isolation. Also, to make jailbreaking/rooting harder.
EDIT: if you want a native SDK on WP7, like I do, please go sign this petition and/or that petition. Thank you!
EDIT: see this.
EDIT: also this. Still not official, but this rumor moves the timeframe for native app support even closer - to the upcoming Tango release.
I believe MS will support native development like C/C++. Really. Seriously.
Because, for end users, one of the killer app is game. And Most of game codes are based on C/C++. JS or C# based codes are exist, but meaningless from industrial perspective. Consider big players in game field like Unreal or EA. They made huge investment on C/C++ codebase. They won't give it up. In other words, MS has no power to force them to spend money for .NET. Even Xbox360 development offers C/C++ development. Because of that.
And leading platforms like iOS/Android all supports native development. WP can't bear up the situation without any game from big players. MS really wants 3rd path games, and offering native code is the only way to get them.
Of course, this can be applied to other apps which are not game, but games are biggest one. When C#/XNA just came out, there's no library. People had to make everything themselves. Now there're a little more, but still meaningless for professional games.
If MS won't offer native environment, just don't go there. MS wants to make developers to use managed .NET code, but .NET has too many limitations can be solved with only unmanaged code.
The only question is just when will MS support native development.
I've been working in C++ in embedded environments for a number of years, developing navigation applications. There is a gaming company in my hometown that I like the look of, but I don't have game development experience. You could consider a navigation app as a type of game, depending on who you are running from.
My question is, what steps should I take to enter the industry? Is it a bad idea to enter the industry at this stage (I'm 30)?
Being 30 doesn't really matter, you can enter the games industry at any age assuming you have the drive and ability.
Start reading about gaming topics, and game development websites (gamedev, gamasutra etc.)
Start writing games. Clones of games you like, your own original ideas, tech demos, anything that you can point to and say "I wrote that, and along the way I learned these things, and solved these problems."
If there is a specific area of interest to you, AI, Rendering, Frontend, Tools & Pipelines, Audio, focus on building game/demo/sample projects that challenge you in that area. "Yeah, I've done that" sounds a lot better in an interview than "yeah I've heard of that".
Get to know people in the industry if you can, through online forums, friends of friends, etc... One good contact can do more for your chances than weeks of demo coding or months of sending resumes out. Game companies may have open houses or job fairs.
The "entry level" jobs in game development are likely to be Frontend or Tools. If you've done navigation apps, sounds like that might be a decent fit for you. If that has included more low level work and optimization on embedded platforms, you might also look at Systems roles.
I'd suggest you start trying to write some games in your spare time. Having some demos is always a good start when you go to an interview and it'll give you some insights into what your job is going to be.
Gamedev.net has an excellent set of tutorials to work through to get a grip of a lot of game-coding concepts.
Do they have any job offerings? If so, look at what they ask for in the CV and start educating yourself in those concepts / technologies.
Contacting them and asking if they have any jobs for an excellent software engineer can't hurt either :)
I see you already accepted an answer, but I'll throw in my two cents:
If the company does console (e.g. Xbox360, PS3) or handheld (e.g. DS, iPhone) games, you should definitely emphasize the embedded aspect of your resume. A few anecdotes about how you optimized the memory layout of a class, or sped up some code by taking advantage of an obscure feature of the chipset will show that you can think like a console programmer. Also, if you did any sort of AI for the navigation apps (e.g. A*, Djikstra), it's good to mention that.
A few people recommended writing games - that's not a bad long term plan if you know you want to get into the industry, but I don't think you should let that stop you from applying to this particular company in the meantime. However you should definitely pick up a copy of one of their recent games, play it for a few hours over the weekend, and be able to say what you liked about it.
As for websites, I second the Gamasutra recommendation, along with Kotaku.
Good luck!
"game industry" is a broad question. There are:
AI programming
Graphic programming.
Sound programming.
Tool programming.
Scripting.
Physics programming.
Network programming.
You probably already can deal with #7, #5 and #4.
As for the rest - mostly it is a dealing with some kind of API, plus you need a very good understanding of 3D math (unless you make 2D game, that is).
For 3d math I cannot help you. I picked info in various non-english sources, and most of them aren't available anymore. However, I think this resource might contain info of interest.
For general 3d graphic info you need to study DirectX SDK and NVidia SDKs (both DirectX and OpenGL), plus there are OpenGL books you HAVE to read:
1. Francis s Hill, "Computer Graphics using OpenGL".
2. OpenGL programming guide aka "Red Book"
3. OpenGL shading language (aka "Orange Book")
4. And you might want to take a look at OpenGL reference manucal ("Blue Book")
I'm talking about OpenGL because while it doesn't offer same level of control for hardware resources, it is easier to get started with than DirectX, and available on larger selection of platforms and have a same power as DirectX. Plus GLSL isn't that different from HLSL (except that GLSL doesn't have remnants of assembly shader programming like HLSL), close enough to C++, so it is relatively easy to get started.
One important thing - if you seriously want to deal with 3D, you have to be able to easily imagine 3d operations in your mind. I.e. how to rotate object, scale object, move object, what matrix means, what is reflection vectors, how to cut polygon with planes, how to find intersection of two meshes, etc, and you should have at least basic understanding of more complex thing like boolean operations on polygonal meshes. I have no idea how to develop this skill (it is very close to "mechanical drawing"), but you'll get a lot of difficulties without it.
Just putting "experienced C++ dev" on your CV will probably get you in the door. The (UK at least) games industry is dominated by graduates and inexperienced programmers - the older ones either burn out or get promoted into management.
A lot of games programming is just programming - the skills are entirely transferable. And your navigation software experience probably puts you in for an AI-related role.
If someone with your background applied to me, I'd certainly give them an interview.
Well I started at 16 with (paid) game development. Search for jobs on websites. Make your own low-budget games and then publish them in a way or another.
If you are good people will search for you, otherwise you have to struggle a bit.
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
I've noticed that chinese mobile phones became very popular, perhaps because of their very reasonable price and many modern features (touch screens, advanced multimedia, double sim cards etc).
I'm wondering if there's any way to develop custom solutions for this handsets as independent developer? How to obtain a toolkit and documentation?
I've found some resources, but mainly inconsistent tech notes, often in chinese only. For now I know, that majority of chinese handsets are based on chips from MediaTek (MTK), with operating system based on Nucleus RTOS and MMI (plutoMMI?) framework. Unfortunately, there is no Java RE avaiable (ok, there are some handsets with Java, however, Java isn't something I'm looking for)
Is there any SDK, documentation, emulators/simulators, how-tos, etc avaiable? How to develop, deploy and test custom application for MTK mobile?
I am enginner at design company. I have MTK development platform for MT series mobiles with English explanation. The original release and manuals are written in English(About 300mb pdf files). The SDK have simulator written in Visual C++. MMI interface working under nucleus rtos os. The codes are V++.
The MTK service is charged. You need to contact them and pay for the chip, software SDK, document, and technical support.
I don't know where you get the "some resource", but it must be leaked by some customer of their, thus using these resource will be considered as illegal.
I work with a lot of Chinese mobile phone manufacturers because we export mobile phones from China. I'm really interested in building a new applications, especially an email program, for these MTK based devices. Now it's a bit late to be looking at the 6225 platform because the 6235 platform seems to be where we'll see the most growth moving forward. The major differences that I'm aware of between the 6235 and 6225 are that 6235 supports Wi-Fi, works with EDGE, and is faster.
Steve, you mentioned the G2. I think that Android will be the breakout OS for Chinese phone manufacturing. Once their local engineers and designers get a handle on it a plethora of both ridiculous and useful applications and models will flourish and there won't be major export (customs) problems as we see now with the Windows Mobile devices (because the Chinese typically don't offer licensed software).
For platform sources this can be a starting point :
https://www.mentor.com/embedded-software/downloads/nucleus-source-interest_reg
I have no real experience on RTOS, I am GNU/Linux guy
I just bought a SciPhone G2 Dream and have done some initial investigation. This particular phone runs J2ME applications but I am also wondering what can be done (if anything) with native applications. Ideally I would like to get my Bluetooth GPS to work with this phone.
This page discusses getting GCC to work with Nucleus but I'm not sure whether this is useful.
Mentor (the makers of Nucleus) have a trial version of their developer suite available. I have just requested a free trial. It is a bit concerning that the website makes no mention of the cost. They also have an emulator.
What sort of phone did you get and what sort of applications are you planning to develop?
I'm in same wagon like you, trying to select an smartphone with WIFI and available SDK, low cost (lower thatn 40$). Also contacted Mediatek without results. I can give you a piece of advice, in reality is what I'm doing now. Try to negotiate a bulk purchase with a supplier together with access to SDK and documentation. I did that before with an ARM based Thinclient and worked, but I had to buy 30 pcs.
I'm not exactly sure of what you mean by a 'Chinese' phone. However, you may be talking about ODM phones. Most of the time, these phones are system clones of regular phones with some customisation. It may be a good idea to just buy one and take it apart to see what platform it runs on. Maybe it uses OMAP or something else? In which case, you probably have more knowledge on how to proceed. Maybe it is even compatible with Linux.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As a novice, I've spent time learning a smattering of C and a fair bit of PHP. I've looked at writing desktop applications for Windows, but there seems to be a fair barrier to entry due to complexity of APIs. Is it worth learning this, or will native applications become less common in the future?
The way I see it, the only desktop application I ever use is a web browser and a text editor as well as the obviously the OS itself. Everything I need is online now.
Is learning to write non-web applications a useful skill going forwards? If so, what should I learn?
I don't think it is ever a good idea to choose one side and stick with it religiously. I think a good engineer will expose themselves to as much as they can so he can make an informed decision about which is the best tool to complete a task.
In other words, don't choose a platform, OS, programming language, etc. and then ignore the others. It is best to be well-rounded in your skill set.
There will always be a market for native apps, although a lot of stuff is moving to the web and there's more scope than ever before for web based apps, native GUI applications are never going to go away entirely.
However, it's really, really hard to give you any really useful advice other than stick with what you like. If you use web stuff exclusively, it would be a bit foolish to go and become a windows GUI programmer :)
This may get modded down - but I'm going to say it anyway.
You can either program or you can't. About 18 months ago when I was looking for a new job, I was looking at the market and I was doing a lot of .NET but a few places wanted me to do JAVA.
I was doing Web Services, they wanted someone to do other stuff...At the end of the day it came down to this - if you know how to code you know how to code. If you're writing desktop apps right now and say in 6-8 months you want to move to some ASP.NET MVC, you'll be fine.
It may take you a bit of start-up time to learn the syntax and get a feel for some things - but in the end you'll be fine. I say this holds true for all the new languages...Skill is skill
Non-web applications will be very useful for the far future (as I see right now). We will not be able to do anything with the efficiency as a well written desktop application online using an interpreted scripting language that has to use a network protocol to communicate with the client.
However, if you are interested in networking, maybe you can try a little of both. Make an rss reader, a simple web browser, or an IRC client. Their all great projects.
You should learn whatever you want to learn. If you don't you'll probably find it harder going than you need to.
I personally started writing desktop applications for Windows, because I used it at the time. These days I do think that you're correct - you can produce a website / online-application without investing so much into the process.
But even writing a decent web application is going to be hard if you're new to programming. A standalone page is simple, but when you add databases, security, and administration into the mix then things can grow.
In my oppinion, a novice should conentrate on the basics and internals of the language of choice. Graphical or web interfaces should wait until you know what you're doing in the backend. I personally would suggest you start with console programs, but I guess that depends on the platform you're using. Maybe desktop interfaces are easier to start with on Windows.
The best practice (in my oppinion) is to write a solid backend with the functionality you want to provide and write it in a modular way, so you can later decide if you want to provide a desktop interface or a web interface (or both). The choice for the user interface shouldn't matter in the beginning.
Learning non-web applications will always be useful. There will always be applications that are not suited to be web apps. Even if everything moved to be a web application, the server side code and web browsers still need to be written.
At this point in time, if you're interested in the Windows platform then I would advise looking into C# and WPF. Those technologies are used in both native and web environments.
Web development is all well and good but the majority of systems even if they have a nice web front end still consist primarily below the web level, a bit like an iceberg.
End most web implementations are n-tier in design with the lower levels like data access and integration with peer servers ocurring in non web languages.
As I see it there seems to be one pervasive language that can touch all these levels and than is .Net Framework. Notice I make no specification about c#, vb etc. I consider that to be a matter of taste. However I can't remember seeing an n-tier banking website using php to do the data layer. Nor an online ordering website that would use ruby to talk to its jd edwards server.
This is where the heavyweight languages still pervade and if thats where you want to work then learning the .Net framework in whatever language variant you choose is the way to go.
Master one discipline then move to the next one.
I am also at the very infancy of learning business application development. The very step I took was to study database. Majority of the applications in the real world is data-centric. It is good to start with desktop application. Do some drag-and-drop then study the code behind. I am doing the same thing with ASP.NET. I have downloaded tons of starter kits. It all depends on your learning style. For me, I can learn more easily by "learn-by-doing" than by digesting chunk after chunk of set theories. That is why cookbook and headfirst books perfectly work for me.
I believe that the future development model for "Web" applications will more akin to the current model of desktop application development. By which I mean that tomorrow's Web apps won't be HTML/AJAX efforts that are difficult and expensive to maintain, debug and test, they'll instead be developed with compiled languages that target a platform that's already available in the browser. Flash, Silverlight, and (to a lesser degree, it appears) Chrome are the current paragons of this idea.
So maybe it's not such a waste of time to learn those "complex" APIs. My group builds WPF applications and I personally don't find those to be any more complex than the the current crop of HTML/AJAX projects.
From your background in languages, I noticed you only mention PHP and C. Neither language is strictly speaking an object-oriented/OO language. You really should learn a traditional OO language like Java or C#, as the majority of jobs are looking for those skills. BTW, read Yegge's advice on what languages a professional developer should learn, and think for yourself about what you should do.
Assuming that you're interested in enterprise application development, I would have to say that that field is transitioning from traditional web development (present stuff from a database on a web page) to rich internet applications (still present data from a database, but the front end begins to approximate a desktop application). Building a rich internet application will require concepts that desktop UI developers have known for a long time. Therefore, I don't think you have to chose between web development and desktop development.
I agree, you should learn what you want to. Once you have an understanding of Web, then learn some desktop programming to broaden your horizons a bit. You'll never know when you'll need it.
But, also, if you're looking at learning windows desktop development, then you should definitely look at C# and/or VB.NET. The .NET Framework is by far the easiest way to develop desktop app for Windows; much easy than C++ from what I understand (I actually didn't spend much time on C++ myself).
#Rich Bradshaw,
I think you can get answer on your question by looking at any job seeking site.
what should I learn?
Whatever you like and can bring you enough money.
Thats a very good question.
I know nowadays that most app development that im aware of is web apps.
But with languages such as flex , i wouldnt be suprised if the desktop apps came back again.
To be well versed you should do both. Skills in one area may or may not translate into the other very well. The lack of state for example trips up lots of desktop developers when they start building web apps. Of course, your experience may vary
A professional .NET programmer should handle both webform and winform.
Even you start from webform, but finally, you will have chance on touch winform.
Just like a topic "VB vs C#", you will not see a .net expert talk about that, because finally, you should know both of them.
There will be cases where things beyond the web can be used:
Scripting languages/console application - build scripts come to mind here for an example but also writing batch or command files to do simple tasks like handle deployment or to do some other simple task that is likely better done from within a black box rather than manually doing something over and over again.
Windows services(WCF) - These are also possibly useful for monitoring things and sending off those, "Server is down!" messages for someone to go and find out what went wrong.
There is also something to be said for middleware and back-end development where one would write web services or handle querying a database or inserting data into a DB that may not be the same of front-end web UI work, just to give a couple of other examples of software development work out there aside from the embedded systems and mobile stuff that is also non-web and non-desktop development in a sense.