This is my first post, so to all of you out there, my name is Joe and I have been following this forum since I decided on buying an ATT Tilt (Kaiser) and you all have been a tremendous help in a lot of decisions I made with my phone.
Now onto the question at hand, I have some programming knowledge in the world of computers (C++, VB, etc...) but I was wondering the differences in trying to make a program for my phone. If someone can direct me to maybe a tutorial or another post that might help me, please do (I looked but couldn't find anything), I would like to start giving back to the forum that helped me out.
There isn't much difference between C++ and VB in general, just some prefer the less strict 'grammar' in VB and some prefer the clear 'grammar' in C++. Speed wise, if you were to be using M$'s classes, both ought to be the same, while if you were to write in pure C++ native language, C ought to be better compiled.
Another alternative would be the .Net thing. If I'm right (haven't been really using one), is a class package for both VB and C+ which seemingly make it easier to program.
Depends on what you have (i.e. the programming software), if you were to have Visual Studio 2003+ (or later, no sure), you can download the WM6 SDK, which includes tutorial on how to get started.
Well what I have on hand right now...nothing at all...I'm at work at the moment and in my freetime here would like to work on a few things, I've been analyzing some other pieces of software since I posted this and noticed the use of XML files for the setup.
I have no preference in what language I use (hell one I don't know yet would work for me...knowledge is a blessing in IT). Just wish to be able to take some of the programs I use at the moment (ex HTC Home, BatteryStatus) add a little more functionality for my own personal use since I really don't feel like copyright lawsuits.
Basically Hanmin, I guess it just boils down to what would you suggest to use with the available "tools" at hand or suggestions, I'm up for anything, new to this game, I figured I would get wisdom from the pros here to make myself useful in my downtime
"There isn't much difference between C++ and VB in general," - now there's a statement to launch a major debate! But I'll resist the temptation and move on to a more constructive response - PPL. PPL (Pocket Programming Language) is a great little package which gives you an IDE for developing pocket pc apps in a C like language on either the pocket pc itself or on a pc. Read about it and get a free trial download here:
http://www.arianesoft.ca/
I've been programming for 3-4 years, about 1-2 of those years in C++(the rest in html, php, gml, js, and crapy stuff like dat). No Java, but I've heard its really easy to learn especially if you already know C++.
anyways, I've read the google tutorials and they haven't helped me since they make you download code instead of writing it (like the notepad tutorial).I've also seen all the videos that explain how android works, and I've read the stuff about it. I just want a tutorial that walks you through the process of programming an application.
basically what I want to learn is:
- How to tell if the user pressed a button, or interacted with a view
- draw an image to the screen
- open and close activities, like for a game you switch from the 1st level to the menu
- How to save data to a file, or database(whichever is best)
and things like displaying a list of items, or an alert and stuff like that.
I already setup eclipse and ran the Hello, Android application in the emulator AND my G1 with adb. So I just need to learn how to write the code
My goal(currently) is to make a picture on the screen move to the right when the user presses something(button, key, trackball, screen), but with my code, not cut & paste. I'll just turn that into a game later.
please help me with this, I've always wanted to develop apps for android(ever since I heard of it ). sorry if this sounds like a retarded question, but I've searched everywhere and I haven't found a good tutorial, and I cant buy a book
PS. I use the eclipse plugin for visually designing the layouts
http://java.sun.com/docs/books/tutorial/
I don't exactly remember from my HTML java applet days, but you can write straight to vm's frame buffer and write a simple program to change the position of the element scrolling it either way you want. Also, java input in html applets can be aided with javascript, so i used javascript to listen for user input and then have java respond to it, but that was over 10 years ago and I dont remember now T_T
really? thats helpful...
EDIT:
I've already read these tutorials on java: http://www.freejavaguide.com/corejava1.htm
I haven't really done anything on the programming side of things since VB6.0. Learned a bit of C once upon a time, but never really got anywhere.
Can any of you fine Devs here point me in the right directions to begin learning how to program for Android? Remember, please, that I will likely have to unlearn some things, and that I have ZERO JAVA experience. I would love to be able to make some apps to fill gaps that I see in the market.
I am running on a dual boot lappy with Win Vista and Linux Mint 10(Ubuntu derivative). Links or pointers to what I need for both sides will be welcomed and appreciated.
im reading hello android v3 and its great so far.. ive also been going thru android source.. download the android sdk and eclipse for linux and or windows.. i prefer linux as does most devs. ive also registered for night time java classes at the local community college for 13 bucks a semester. anyways goodluck!
This might be helpful for basic syntax stuff.
Start with fattire's link and pick up the Java basics. To read Android examples, you'll need to understand how Classes and Interfaces work as well as how to extend and implement them, respectively. You'll also want to understand inner classes and anonymous inner classes. Understand variable scoping in classes.
Learn how threads work. Understand the implications of multithreading and reentrance. Experiment a lot in simple, stand-alone samples.
Once you've gotten started with Java, you can download Eclipse and the Android SDK. Here's the Android "Hello World" tutorial, which is a reasonable place to start. It has pointers to everything you'll need.
http://developer.android.com/guide/tutorials/hello-world.html
Android Applications are pretty straightforward once you understand the basics... AppWidgets and Services are less so. The trick is to understand the lifecycle of each -- where and when it's appropriate to do what sorts of work and how to communicate results between different components. It will be rough going in the beginning with a fair amount of crashing as you discover you're taking too long to do something that really should be offloaded to a different part of the lifecycle or a whole new thread -- or when you discover you can't do something you want, directly, because you lack the parts and have to send a message to something that does have all the parts.
My first project was a simple button on the home screen that, in effect, runs a few commands. It took me more than a week to make it work properly, and I was already familiar with Java.
Also understand that some of the examples floating around -- even those from Google employees -- are old and that Android has had some growing pains. Double check the approach suggested by anything that's older than a year. The SDK contains sample programs that make for decent cookbook code.
thanks to all of you...as well as the mod who moved the thread to the correct spot...wasn't sure if this was the correct one.
Hello android (as mentioned above) is awesome! Another good one is Beginning Android 2. Both found here:]
Hello Android
Beginning Android
I was just reading an article concerning malware on Windows Phone 8
Google News Search "Windows Phone 8 Malware"
From the article
"A 16-year-old security researcher from India plans to present a malware application for Windows Phone 8 at the upcoming MalCon security conference in New Delhi, India, on Nov. 24.
According to a brief description of the presentation on the MalCon website, it will show approaches and techniques for infecting Windows Phone 8 devices and will demonstrate how the prototype malware can steal contacts, upload pictures, access text messages and more."
Will this affect WP8 sales...it certainly doesn;t look good for this to happen so close to the launch...will we need to install AV software on our phones now too?
"Stealing contacts" is not that hard to do, since your app can read the contacts (you don't need any hacking to do that).
But reading + sending them to your server will make the marketplace instantly reject the app. So i doubt there's a problem.
I also don't see how you can infect a windows phone, given that .Net and Secure Boot make it almost invulnerable to everything.
rob243 said:
I was just reading an article concerning malware on Windows Phone 8
Google News Search "Windows Phone 8 Malware"
From the article
"A 16-year-old security researcher from India plans to present a malware application for Windows Phone 8 at the upcoming MalCon security conference in New Delhi, India, on Nov. 24.
According to a brief description of the presentation on the MalCon website, it will show approaches and techniques for infecting Windows Phone 8 devices and will demonstrate how the prototype malware can steal contacts, upload pictures, access text messages and more."
Will this affect WP8 sales...it certainly doesn;t look good for this to happen so close to the launch...will we need to install AV software on our phones now too?
Click to expand...
Click to collapse
Unless you unlock the device and install that software by yourself, i don't believe it ever gonna pass marketplace check before it get online.
Well I am interested to see how its done, apparently the guy will present the proof of concept on the 24th
There are ways to get past checks run in the Marketplace ingestion. This has been previously demonstrated with PoC malware on iOS, which has similar protections. Don't assume it's impossible, especially if native code use is permitted.
Please note that there is a difference between native and unmanaged code, don't mix them up.
Native code has always run on Windows Phone. Both C++ and C# produce native code. The first is un-managed, whereas the second is managed.
Visual C++, the one we use in Windows Phone is, just like C#, a managed native language. It achieves almost the same performance as the standard C++,due to the more optimized compiler. It is possible to run standard C++ on Windows Phone, but it is very difficult to do so because the marketplace knows which compiler you used to make your app (if visual studio is not there, no no). The marketplace also knows which API you use (no Windows Phone API for C++, again a big NO for the submission).
Now, the difference between native and non-native code...
Native code always ends up as 1 and 0. The very code you write in C# will, at some point, end up as 1s and 0s. Same goes for C++(managed or not). The difference between C# and C++ is that the compiler inserts some failsafes into the code (lots of ifs) to check for exceptions. This does not happen in C++.
So the path for C# is like this:
C# code -> MSIL->Native code which is run on your devices (compilation is either done at install time, or in the clouds).
the C++ code we use in Windows Phone has basically the same path! However, the more mature compiler and the "no-failsafe policy unless instructed to" that all C++ variations enforce make the code faster while less safer.
A non-native language will never, ever get the code a developer writes compiled to 1s and 0s.
Such an example are web programming languages, and Java.
For Java, the process is like this
Java code -> various stages of compilation>byte code -> JVM interprets bytecode and then sends 1s and 0s to the CPU to execute-> CPU sends 1s and 0s results back to JVM which displays the results.
As such, Java is somewhat safer than C#, but also a lot slower.
The advantage of using an interpreted language is that you know the hardware capabilities of the device beforehand, and optimizations can be made on the spot.
Microsoft, however, took the middle road with C#. They gave it all the advantages of an intepreted language (due to the MSIL step, the .Net always knows how hardware it runs on, so the MSIL will always target all the hardware capabilities for your CPU, GPU and RAM), while also running on native code, which makes it very fast. They also decided to push in the same failsafe checks Java inserts in its code. This resulted in a slightly slower code when compared to C++.
As a developer, I think the reason for dropping XNA development by Microsoft wasn't its speed. C# could easily run games, and the thousand XNA games we have on the marketplace bear testimony to that. They brought C++ on board because porting apps from one platform to another would be easier this way, especially for apps coming from android or iOS).
Anyway, having said that, the C++ we use on phones does not have the capabilities to access the hardware or the system the same way it has on desktop. It doesn't have more power than C# already did. It is just used there for other reasons. I don't think it will pose any threat to security. Desktop evolved in a different way. Microsoft learned the lesson of system protection a long time ago. They won't repeat the same mistakes now. It wouldn't surprise me if they actually had some sort of AV software built in, just to be sure.
There are so many factual errors in the above post I don't even know where to begin...
"Native" in this sense refers to apps written in a language which gets built ("compiled" although that technically involves compiling, assembling, and linking) directly into machine code ("0s and 1s" is a silly way to describe it, since *everything* on a computer, from programs to plain text files to MSIL or Java bytecode are all binary). Machine code means a binary sequence that the processor can directly execute. This is also referred to as native code, i.e. code which executes on the processor without needing an intermediary layer.
Although technically "native" and "unmanaged" mean different things, the difference is not what you think it is, and it's not very relevant to this discussion. It's entirely possible to have a native managed language ("D" was supposed to be such a thing; I'm not sure to what degree managed C++ qualifies) and to have intermediate-compiled unmanaged languages (you could, for example, distribute unmanaged programs compiled to LLVM bytecode; some systems might actually be doing so). However, MS themselves typically use "native" to mean "not managed", as evidenced by things like debugger modes.
These days, almost everything gets JIT (Just In Time) compiled to machine code even if the build tool didn't produce native machine code itself. This applies to .NET code (gets built as MSIL), Java (gets built to Java bytecode or Dalvik bytecode if on Android), JavaScript (doesn't go through a build process at all, but modern browsers JIT compile it to native before execution nonetheless), and many other languages. Interpreting is slow and requires a lot of memory overhead as well (you have to run the interpreter in parallel with the program actually being executed).
Although it is possible to invoke managed code from native code (only a little messy) and vice-versa (very common, see P/Invoke or COM interop for .NET, or JNI for Java), this should not be confused with them being the same thing. Yes, by the time they reach the CPU instruction decoder they're the same, but the process of loading the program, and the "runtime" environment that it interacts with, are very different indeed. Managed code uses a memory manager (hence the name), which takes care of things like defragmenting and freeing memory (via the garbage collector). This fundamentally violates a number of assumptions common to unmanaged code, such as that the address of data in memory will never change on its own, and that once allocated, a block of memory on the heap remains reserved until manually freed.
Another important difference is that managed languages must use abstractions of function pointers (for example, .NET delegates). In native languages it is possible (though generally unwise) to specify an absolute address (0x040C7F06 or some such) as a function pointer, and call that "function" (which results in the processor attempting to execute instructions starting from that memory address). In practice, this kind of thing is almost never done in PC software; it's bug-prone, completely un-portable, incompatible with security features like ASLR, very difficult to debug (this is the kind of thing that malware might use to make reverse engineering it harder), and there's typically no reason at all to do so.
However, the fact that it's *possible* is a Big Freaking Deal for somebody looking to work around a runtime security check. Consider this: Sliverlight on WP7 doesn't allow arbitrary LoadLibrary (or Assembly.Load, or similar) calls. The APIs available to your app are the ones included in its DLLs, and the ones in the Silverlight for WP7 runtime libraries. Even though the desired functions exist on the OS, and are even linked into program memory, you can't call them because there's no way to get a delegate for them. Now, compare this to native code, where you can literally just scan the code section of your app's memory until you find the entry point for the function you want, then treat that address as a function pointer and jump right into it.
Now, to be fair, I haven't actually written any official WP8 C++ yet. However, I can tell you that the trick mentioned above works just fine in Windows Runtime C++ on both Win8 and Windows RT, which are also supposed to lack APIs like LoadLibrary, and I therefore suspect it will work fine on WP8. Some experimentation is due, in any case.
GoodDayToDie said:
There are so many factual errors in the above post I don't even know where to begin...
"Native" in this sense refers to apps written in a language which gets built ("compiled" although that technically involves compiling, assembling, and linking) directly into machine code ("0s and 1s" is a silly way to describe it, since *everything* on a computer, from programs to plain text files to MSIL or Java bytecode are all binary). Machine code means a binary sequence that the processor can directly execute. This is also referred to as native code, i.e. code which executes on the processor without needing an intermediary layer.
Although technically "native" and "unmanaged" mean different things, the difference is not what you think it is, and it's not very relevant to this discussion. It's entirely possible to have a native managed language ("D" was supposed to be such a thing; I'm not sure to what degree managed C++ qualifies) and to have intermediate-compiled unmanaged languages (you could, for example, distribute unmanaged programs compiled to LLVM bytecode; some systems might actually be doing so). However, MS themselves typically use "native" to mean "not managed", as evidenced by things like debugger modes.
These days, almost everything gets JIT (Just In Time) compiled to machine code even if the build tool didn't produce native machine code itself. This applies to .NET code (gets built as MSIL), Java (gets built to Java bytecode or Dalvik bytecode if on Android), JavaScript (doesn't go through a build process at all, but modern browsers JIT compile it to native before execution nonetheless), and many other languages. Interpreting is slow and requires a lot of memory overhead as well (you have to run the interpreter in parallel with the program actually being executed).
Although it is possible to invoke managed code from native code (only a little messy) and vice-versa (very common, see P/Invoke or COM interop for .NET, or JNI for Java), this should not be confused with them being the same thing. Yes, by the time they reach the CPU instruction decoder they're the same, but the process of loading the program, and the "runtime" environment that it interacts with, are very different indeed. Managed code uses a memory manager (hence the name), which takes care of things like defragmenting and freeing memory (via the garbage collector). This fundamentally violates a number of assumptions common to unmanaged code, such as that the address of data in memory will never change on its own, and that once allocated, a block of memory on the heap remains reserved until manually freed.
Another important difference is that managed languages must use abstractions of function pointers (for example, .NET delegates). In native languages it is possible (though generally unwise) to specify an absolute address (0x040C7F06 or some such) as a function pointer, and call that "function" (which results in the processor attempting to execute instructions starting from that memory address). In practice, this kind of thing is almost never done in PC software; it's bug-prone, completely un-portable, incompatible with security features like ASLR, very difficult to debug (this is the kind of thing that malware might use to make reverse engineering it harder), and there's typically no reason at all to do so.
However, the fact that it's *possible* is a Big Freaking Deal for somebody looking to work around a runtime security check. Consider this: Sliverlight on WP7 doesn't allow arbitrary LoadLibrary (or Assembly.Load, or similar) calls. The APIs available to your app are the ones included in its DLLs, and the ones in the Silverlight for WP7 runtime libraries. Even though the desired functions exist on the OS, and are even linked into program memory, you can't call them because there's no way to get a delegate for them. Now, compare this to native code, where you can literally just scan the code section of your app's memory until you find the entry point for the function you want, then treat that address as a function pointer and jump right into it.
Now, to be fair, I haven't actually written any official WP8 C++ yet. However, I can tell you that the trick mentioned above works just fine in Windows Runtime C++ on both Win8 and Windows RT, which are also supposed to lack APIs like LoadLibrary, and I therefore suspect it will work fine on WP8. Some experimentation is due, in any case.
Click to expand...
Click to collapse
Well, I was just trying to get a "basic picture" of the thing, but thanks for going into much more details.
As I said, the C++ we use in Windows Phone, just like C# on Windows Phone, functions in a different way compared to Desktop or Tablet version(hell, with C# on desktop you can easily do the memory scan thing and find stuff in the OS, not only in your app, but that is generally not needed, since C# on desktop has a much boarder and less limited API) . Unlike the former two, you can't interact outside your application, because your application is sandboxed. Even if you did find the pointer to a system protected function, you wouldn't be able to do squat with it(the system protects itself). Which is why I said C++ can't do things C# already couldn't. In theory, yes you can do what you said, in fact, i expect it to be possible on rooted rooms, but for the average joe...well...it very unlikely to happen, unless he does something stupid.
As for the JIT story, well, yes, Java does use JIT. However, it does so because it doesn't know before hand on what hardware it will run. The same happens with C# and .Net on desktop, and this is due to hardware variations. Right now, for windows phone, the "JIT" occurs directly in the clouds, or at install time, as all Windows Phones (8) use snapdragon chips.
I didn't say there were no differences between the code C# and C++ create at run time. The abstraction layers inserted by the compiler fall under the "failsafes inserted in code that slow things down", which C++ doesn't have. Also the more mature compiler (C++has like 40 years of xp, C# barely made 10, and only 3 on Windows Phone), the "true native" (happy now?) code it generates (which is very close to assembler language) makes C++ faster than C#, but not fast enough nor safe enough to phase out C# entirely.
In fact, if we still have this board 10 years from now, we might C# eventually take down C++.
We should avoid getting into a technical talk in this thread. As you can see, there are non-developers coming by, and an answer such as yours will completely and utterly confuse them. What I attempted to provide was a very basic image they could understand, like JVM sending 1s and 0s to CPU is the same as JIT.
Let's wait and see what we will be presented with. Currently the only thing a WP8 Managed App can't do that was mentioned was reading the SMS-Storage. Everything else is part of the official APIs. It might be that similarily to several WP7 hacks OEM drivers are being used to gain access.
The only thing that would really worry me was if he was able to provide a way to install his Malware bypassing the Marketplace. It might be interesting though for the Jailbreak community, given that any jailbreak bascially means exploiting a security vulnerability to elevate the rights of the current process to allow for those unlocks.