Related
Hi @all,
yesterday i posted a nice article about how HW Acceleration is done since honeycomb (and the difference before).
I think its a good idea to post here nice and interesting articles - this can help the devs here but the users to why
sometimes its simply impossible to code things or fix things.
Please dont spam this thread, even its in general section - let users read interesting things instead of pages full of ****
"The Reason Android is Laggy"
Dianne starts off her post with a surprising revelation:
“Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering.
This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no
trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen.”
Hun? How can this be the case? Anybody who’s used a Nexus S knows it slows down in all but the simplest of ListViews.
And forget any semblance of decent performance if a background task is occurring, like installing an app or updating the
UI from disk. On the other hand, iOS is 100% smooth even when installing apps. But we know Dianne isn’t lying about the
potential CPU performance, so what’s going on?
The Root Cause
It’s not GC pauses. It’s not because Android runs bytecode and iOS runs native code. It’s because on iOS all UI rendering
occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering
occurring on the main thread with normal priority.
This is a not an abstract or academic difference. You can see it for yourself. Grab your closest iPad or iPhone and open Safari.
Start loading a complex web page like Facebook. Half way through loading, put your finger on the screen and move it around.
All rendering instantly stops. The website will literally never load until you remove your finger. This is because the UI thread is
intercepting all events and rendering the UI at real-time priority.
If you repeat this exercise on Android, you’ll notice that the browser will attempt to both animate the page and render the HTML,
and do an ‘ok’ job at both. On Android, this a case where an efficient dual core processor really helps, which is why the Galaxy
S II is famous for its smoothness.
On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until
all rendering is finished. Android tries to do both at the same priority, so the frame rate suffers. Once you notice this happening,
you’ll see it everywhere on an Android phone. Why is scrolling in the Movies app slow? Because movie cover thumbnails are
dynamically added to the movie list as you scroll down, while on iOS they are lazily added after all scrolling stops.
Other Reasons
The fundamental reason Android is laggy is UI rendering threading and priority, but it’s not the only reason. First, hardware
acceleration, despite Dianna’s reservations, does help. My Nexus S has never been snappier since upgrading to ICS. Hardware
acceleration makes a huge difference in apps like the home screen and Android market. Offloading rendering to the GPU also
increases battery life, because GPUs are fixed-function hardware, so they operate at a lower power envelope.
Second, contrary to what I claimed earlier, garbage collection is still a problem, even with the work on concurrent GC in Dalvik.
For example, if you’ve ever used the photo gallery app in Honeycomb or ICS you may wonder why the frame rate is low. It turns
out the frame rate is capped at 30 FPS because without the cap, swiping through photos proceeds at 60 FPS most of the time,
but occasionally a GC pause causes a noticeable “hiccup”. Capping the frame rate at 30 fixes the hiccup problem at the expense
of buttery smooth animations at all times.
Third, there are the hardware problems that Dianne discussed. The Tegra 2, despite Nvidia’s grandiose marketing claims, is hurt
by low memory bandwidth and no NEON instruction set support (NEON instructions are the ARM equivalent of Intel’s SSE, which
allow for faster matrix math on CPUs). Honeycomb tablets would be better off with a different GPU, even if it was theoretically
less powerful in some respects than the Tegra 2. For example, the Samsung Hummingbird in the Nexus S or Apple A4. It’s telling
that the fastest released Honeycomb tablet, the Galaxy Tab 7.7, is running the Exynos CPU from the Galaxy S II.
Fourth, Android has a ways to go toward more efficient UI compositing. On iOS, each UI view is rendered separately and stored
in memory, so many animations only require the GPU to recomposite UI views. GPUs are extremely good at this. Unfortunately, on
Android, the UI hierarchy is flattened before rendering, so animations require every animating section of the screen to be redrawn.
Fifth, the Dalvik VM is not as mature as a desktop class JVM. Java is notorious for terrible GUI performance on desktop. However,
many of the issues don’t carry over to the Dalvik implementation. Swing was terrible because it was a cross platform layer on top
of native APIs. It is interesting to note that Windows Phone 7’s core UI is built in native code, even though the original plan was to
base it entirely on Silverlight. Microsoft ultimately decided that to get the kind of UI performance required, the code would have to
be native. It’s easy to see the difference between native and bytecode on Windows Phone 7, because third party apps are written
in Silverlight and have inferior performance (NoDo and Mango have alleviated this problem and the Silverlight UIs are generally very
smooth now).
Thankfully, each of the five issues listed above is solvable without radical changes to Android. Hardware acceleration will be on all
Android phones running ICS, Dalvik continues to improve GC efficiency, the Tegra 2 is finally obsolete, there are existing workarounds
for the UI compositing problems, and Dalvik becomes a faster VM with every release. I recently asked +Jason Kincaid of +TechCrunch
if his Galaxy Nexus was smooth, and he had this to say:
“In general I've found ICS on the Galaxy Nexus to be quite smooth. There are occasional stutters — the one place where I can
consistently get jitters on the Galaxy Nexus is when I hit the multitasking button, where it often will pause for a quarter second.
That said, I find that the iPhone 4S also jitters more than I had expected, especially when I go to access the systemwide search
(where you swipe left from the home screen).”
So there you go, the Android lag problem is mostly solved, right? Not so fast.
Going Forward
Android UI will never be completely smooth because of the design constraints I discussed at the beginning:
- UI rendering occurs on the main thread of an app
- UI rendering has normal priority
Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these
two design constraints remain true. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year
old iPhone. So why did the Android team design the rendering framework like this?
Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry.
The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device.
When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI
framework.
This is the same reason why Windows Mobile 6.5, Blackberry OS, and Symbian have terrible touch screen performance. Like Android, they
were not designed to prioritise UI rendering. Since the iPhone’s release, RIM, Microsoft, and Nokia have abandoned their mobile OS’s and
started from scratch. Android is the only mobile OS left that existed pre-iPhone.
So, why doesn’t the Android team rewrite the rendering framework? I’ll let Romain Guy explain:
“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the
biggest problem. We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing,
possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to
this also.”
Romain doesn’t elaborate on what the downsides are, but it’s not difficult to speculate:
- All Apps would have to be re-written to support the new framework
- Android would need a legacy support mode for old apps
- Work on other Android features would be stalled while the new framework is developed
However, I believe the rewrite must happen, despite the downsides. As an aspiring product manager, I find Android’s lagginess absolutely
unacceptable. It should be priority #1 for the Android team.
When the topic of Android comes up with both technical and nontechnical friends, I hear over and over that Android is laggy and slow.
The reality is that Android can open apps and render web pages as fast or faster than iOS, but perception is everything. Fixing the UI lag
will go a long way to repairing Android’s image.
Beyond the perception issue, lag is a violation of one of Google’s core philosophies. Google believes that things should be fast. That’s a driving
philosophy behind Google Search, Gmail, and Chrome. It’s why Google created SPDY to improve on HTTP. It’s why Google builds tools to help
websites optimize their site. It’s why Google runs it’s own CDN. It’s why Google Maps is rendered in WebGL. It’s why buffering on Youtube is
something most of us remember, but rarely see anymore.
But perhaps the most salient reason why UI lag in Android is unacceptable comes from the field of Human-Computer Interaction (HCI). Modern
touch screens imply an affordance language of 1 to 1 mapping between your finger and animations on the screen. This is why the iOS over-scroll
(elastic band) effect is so cool, fun, and intuitive. And this is why the touch screens on Virgin America Flights are so frustrating: they are incredibly
laggy, unresponsive, and imprecise.
A laggy UI breaks the core affordance language of a touch screen. The device no longer feels natural. It loses the magic. The user is pulled out of
their interaction and must implicitly acknowledge they are using an imperfect computer simulation. I often get “lost” in an iPad, but I cringe when a
Xoom stutters between home screens. The 200 million users of Android deserve better.
And I know they will have it eventually. The Android team is one of the most dedicated and talented development teams in the world. With stars like
+Dianne Hackborn and +Romain Guy around, the Android rendering framework is in good hands.
I hope this post has reduced confusion surrounding Android lag. With some luck, Android 5.0 will bring the buttery-smooth Android we’ve all dreamed
about since we first held an HTC G1. In the mean time, I’ll be in Redmond working my butt off trying to get a beautiful and smooth mobile OS some
of the recognition it deserves.
Click to expand...
Click to collapse
How do Android Apps work- Java, its compilation and role of DalvikVM
OK, here goes mine..
was researching around about the role of java in android and I found this piece of info..
it explains the way android apps work and stuff..
Visit here for the full article..
What is Java?
Android applications are developed using the Java language. As of now, that’s really your only option for native applications. Java is a very popular programming language developed by Sun Microsystems (now owned by Oracle). Developed long after C and C++, Java incorporates many of the powerful features of those powerful languages while addressing some of their drawbacks. Still, programming languages are only as powerful as their libraries. These libraries exist to help developers build applications.
Some of the Java’s important core features are:
It’s easy to learn and understand
It’s designed to be platform-independent and secure, using
virtual machines
It’s object-oriented
Android relies heavily on these Java fundamentals. The Android SDK includes many standard Java libraries (data structure libraries, math libraries, graphics libraries, networking libraries and everything else you could want) as well as special Android libraries that will help you develop awesome Android applications.
Why is Platform Independence Important?
With many programming languages, you need to use a compiler to reduce your code down into machine language that the device can understand. While this is well and good, different devices use different machine languages. This means that you might need to compile your applications for each different device or machine language—in other words, your code isn’t very portable. This is not the case with Java. The Java compilers convert your code from human readable Java source files to something called “bytecode” in the Java world. These are interpreted by a Java Virtual Machine, which operates much like a physical CPU might operate on machine code, to actually execute the compiled code. Although it might seem like this is inefficient, much effort has been put into making this process very fast and efficient. These efforts have paid off in that Java performance in generally second only to C/C++ in common language performance comparisons.
Android applications run in a special virtual machine called the Dalvik VM. While the details of this VM are unimportant to the average developer, it can be helpful to think of the Dalvik VM as a bubble in which your Android application runs, allowing you to not have to worry about whether the device is a Motorola Droid, an HTC Evo, or the latest toaster running Android. You don’t care so long as the device is Dalvik VM friendly—and that’s the device manufacturer’s job to implement, not yours.
Why is Java Secure?
Let’s take this bubble idea a bit further. Because Java applications run within the bubble that is a virtual machine, they are isolated from the underlying device hardware. Therefore, a virtual machine can encapsulate, contain, and manage code execution in a safe manner compared to languages that operate in machine code directly. The Android platform takes things a step further. Each Android application runs on the (Linux-based) operating system using a different user account and in its own instance of the Dalvik VM. Android applications are closely monitored by the operating system and shut down if they don’t play nice (e.g. use too much processing power, become unresponsive, waste resources, etc.). Therefore, it’s important to develop applications that are stable and responsive. Applications can communicate with one another using well-defined protocols.
Compiling Your Code
Like many languages, Java is still a compiled language even though it doesn’t compile all the way down to machine code. This means you, the developer, need to compile your Android projects and package them up to deploy onto devices. The Eclipse development environment (used with the Android Development plug-in) makes this pretty painless. In Eclipse, automatic compilation is often turned on by default. This means that every time you save a project file, Eclipse recompiles the changes for your application package. You immediately see compile errors. Eclipse also interprets Java as you type, providing handy code coloring and formatting as well as showing many types of errors as you go. Often, you can click on the error and have Eclipse automatically fix a typo, or add an import statement, or provide a method stub for you, saving lots of typing.
You can still manually compile your code if you so desire. Within Eclipse, you’ll find the Build settings under the project menu. If you have “Build Automatically” turned on, you can still choose the “Clean…” option that will allow you to do full rebuild of all files. If “Build Automatically” is turned off, “Build All” and “Build Project” menu options are enabled. “Build All” means to build all of the projects in the workspace. You can have many projects in an Eclipse workspace.
The build process, for regular Java projects, results in a file with the extension of JAR – Java ARchive. Android applications take JAR files and package them for deployment on devices as Android PacKage files with an extension .apk. These formats not only include your compiled Java code, but also any other resources, such as strings, images, or sound files, that your application requires to run as well as the Application Manifest file, AndroidManifest.xml. The Android Manifest file is a file required by all Android applications, which you use to define configuration details about your app.
Click to expand...
Click to collapse
And here goes another article, by an Ex-Intern Andrew Munn who worked on the android project..
i just post the link here, its a huge article...
Follow up to “Android graphics true facts”, or The Reason Android is Laggy
Click to expand...
Click to collapse
An Extremely important thread for me..........My friend has an iPhone 3GS and he always considers it better than Android, underestimating my LG O1 I've many a times proved him wrong, but not with technical aspects.....Now he'd understand what is ANDROID!!!!
D3oDex3D_Ayush717 said:
An Extremely important thread for me..........My friend has an iPhone 3GS and he always considers it better than Android, underestimating my LG O1 I've many a times proved him wrong, but not with technical aspects.....Now he'd understand what is ANDROID!!!!
Click to expand...
Click to collapse
exactly ! android is 100 times better and powerfull than ios ! if in an iphone ui rendering didnt happen didicatedly, it would be 100 times more laggy than android. one other thing that shows that ios does concentrate completly on ui when scrolling- swipe left right through homscreens in speed (even with all apps closed) - ull see that the dots below which indicate which screen ur on , doesnt change at all untill uve stopped scrolling and then it moves directly to the current screen indicator!
---------- Post added at 03:16 PM ---------- Previous post was at 03:09 PM ----------
btw this here is a contradicting article to what andy you posted ! here ! :
Dianne Hackborn - 00:38 (edited) - Public
A few days ago I wrote a post trying to correct a lot of the inaccurate statements I have seen repeatedly mentioned about how graphics on Android works. This resulted in a lot of nice discussion, but unfortunately has also lead some people to come up with new, novel, and often technically inaccurate complaints about how Android works.
These new topics have been more about some fundamental design decisions in Android, and why they are wrong. I’d like to help people better understand (and judge) these discussions by giving some real background on why Android’s UI was designed the way it is and how it actually works.
One issue that has been raised is that Android doesn’t use thread priorities to reduce how much background work interrupts the user interface. This is outright wrong. It actually uses a number of priorities, which you can even find defined right here http://developer.android.com/reference/android/os/Process.html#THREAD_PRIORITY_AUDIO in the SDK.
The most important of these are the background and default priorities. User interface threads normally run at the default priority; background threads run in the background priority. Application processes that are in the background have all of their threads forced to the background priority.
Android’s background priority is actually pretty interesting. It uses a Linux facility called cgroups to put all background threads into a special scheduling group which, all together, can’t use more than 10% of the CPU. That is, if you have 10 processes in the background all trying to run at the same time, when combined they can't take away more than 10% of the time needed by foreground threads. This is enough to allow background threads to make some forward progress, without having enough of an impact on the foreground threads to be generally visible to the user.
(You may have noticed that a “foreground” priority is also defined. This is not used in current Android; it was in the original implementation, but we found that the Linux scheduler does not give enough preference to threads based on pure priority, so switched to cgroups in Android 1.6.)
I have also seen a number of claims that the basic Android design is fundamentally flawed and archaic because it doesn’t use a rendering thread like iOS. There are certainly some advantages to how iOS work, but this view is too focused on one specific detail to be useful, and glosses over actual similarities in how they behave.
Android had a number of very different original design goals than iOS did. A key goal of Android was to provide an open application platform, using application sandboxes to create a much more secure environment that doesn’t rely on a central authority to verify that applications do what they claim. To achieve this, it uses Linux process isolation and user IDs to prevent each application from being able to access the system or other application in ways that are not controlled and secure.
This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all.
An important part of achieving this security is having a way for (EDIT: It has been pointed out to me that iOS does in fact use multiple windows and multiple GL contexts. Lesson to me, just don't talk about anything I haven't directly verified. That still doesn't change things for Android, though, where as I mention later we simply did not have hardware and drivers that could do multiple GL contexts until fairly recently.)
individual UI elements to share the screen in a secure way. This is why there are windows on Android. The status bar and its notification shade are windows owned and drawn by the system. These are separate from the application’s window, so the application can not touch anything about the status bar, such as to scrape the text of SMS messages as they are displayed there. Likewise the soft keyboard is a separate window, owned by a separate application, and it and the application can only interact with each other through a well defined and controlled interface. (This is also why Android can safely support third party input methods.)
Another objective of Android was to allow close collaboration between applications, so that for example it is easy to implement a share API that launches a part of another application integrated with the original application’s flow. As part of this, Android applications traditionally are split into pieces (called “Activities”) that handle a single specific part of the UI of the application. For example, the contacts lists is one activity, the details of a contact is another, and editing a contact is a third. Moving between those parts of the contacts UI means switching between these activities, and each of these activities is its own separate window.
Now we can see something interesting: in almost all of the places in the original Android UI where you see animations, you are actually seeing windows animate. Launching Contacts is an animation of the home screen window and the contacts list window. Tapping on a contact to see its details is an animation of the contacts list window and the contacts details window. Displaying the soft keyboard is an animation of the keyboard window. Showing the dialog where you pick an app to share with is an animation of a window displaying that dialog.
When you see a window on screen, what you are seeing is actually something called a “surface”. This is a separate piece of shared memory that the window draws its UI in, and is composited with the other windows to the screen by a separate system service (in a separate thread, running at a higher than normal priority) called the “surface flinger.” Does this sound familiar? In fact this is very much like what iOS is doing with its views being composited by a separate thread, just at a less fine-grained but significantly more secure level. (And this window composition has been hardware accelerated in Android from the beginning.)
The other main interesting interaction in the UI is tracking your finger -- scrolling and flinging a list, swiping a gallery, etc. These interactions involve updating the contents inside of a window, so require re-rendering that window for each movement. However, being able to do this rendering off the main thread probably doesn’t gain you much. These are not simple “move this part of the UI from X to Y, and maybe tell me when you are done” animations -- each movement is based on events received about the finger on the screen, which need to be processed by the application on its main thread.
That said, being able to avoid redrawing all of the contents of the parts of the UI that are moving can help performance. And this is also a technique that Android has employed since before 1.0; UI elements like a ListView that want to scroll their content can call http://developer.android.com/reference/android/view/View.html#setDrawingCacheEnabled(boolean) to have that content rendered into a cache so that only the bitmap needs to be drawn as it moves.
Traditionally on Android, views only have their drawing cache enabled as a transient state, such as while scrolling or tracking a finger. This is because they introduce a fair amount more overhead: extra memory for the bitmap (which can easily total to multiple times larger than the actual frame buffer if there are a number of visual layers), and when the contents inside of a cached view need to be redrawn it is more expensive because there is an additional step required to draw the cached bitmap back to the window.
So, all those things considered, in Android 1.0 having each view drawn into a texture and those textures composited to the window in another thread is just not that much of a gain, with a lot of cost. The cost is also in engineering time -- our time was better spent working on other things like a layout-based view hierarchy (to provide flexibility in adjusting for different screen sizes) and “remote views” for notifications and widgets, which have significantly benefited the platform as it develops.
In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently. Because Android is designed around having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time. The hardware at that time just didn’t support this, even ignoring the additional memory needed for it that was not available. Even today we are in the early stages of this -- most mobile GPUs still have fairly expensive GL context switching.
I hope this helps people better understand how Android works. And just to be clear again from my last point -- I am not writing this to make excuses for whatever things people don’t like about Android, I just get tired of seeing people write egregiously wrong explanations about how Android works and worse present themselves as authorities on the topic.
There are of course many things that can be improved in Android today, just as there are many things that have been improved since 1.0. As other more pressing issues are addressed, and hardware capabilities improve and change, we continue to push the platform forward and make it better.
One final thought. I saw an interesting comment from Brent Royal-Gordon on what developers sometimes need to do to achieve 60fps scrolling in iOS lists: “Getting it up to sixty is more difficult—you may have to simplify the cell's view hierarchy, or delay adding some of the content, or remove text formatting that would otherwise require a more expensive text rendering API, or even rip the subviews out of the cell altogether and draw everything by hand.”
I am no expert on iOS, so I’ll take that as as true. These are the exact same recommendations that we have given to Android’s app developers, and based on this statement I don't see any indication that there is something intrinsically flawed about Android in making lists scroll at 60fps, any more than there is in iOS.
D3oDex3D_Ayush717 said:
An Extremely important thread for me..........My friend has an iPhone 3GS and he always considers it better than Android, underestimating my LG O1 I've many a times proved him wrong, but not with technical aspects.....Now he'd understand what is ANDROID!!!!
Click to expand...
Click to collapse
Ehhhh I still think 3GS is better than optimus one
That's a lot of bull**** in even more words...
Kidding
But I don't understand anything of it, I'll leave it to the real devs (A)
Luck dev'ing
ok, here some basic informations on how long it take and why before a developer can
release a complete OS:
http://developer.sonyericsson.com/w...from-source-code-release-to-software-upgrade/
About Accelerated Android Rendering:
It's pretty interesting although these guys aren't talking about Ice Cream Sandwich (they're talking about Honeycomb that introduced hardware accelerated 2D rendering)
http://www.youtube.com/watch?v=v9S5EO7CLjo
I could be way off base here, but is there anything useful that could be extracted from qualcomm's adreno sdk?
https://developer.qualcomm.com/
terratrix said:
Ehhhh I still think 3GS is better than optimus one
Click to expand...
Click to collapse
I am not comparing 3Gs and O1, am talking abt. difference between AndroidOS and iOS............
Sent from my LG Optimus One P500 using XDA App
This week, google started a nice topic on the android developer page "Best practices to develop android applications".
Reading some articles is recommended for developers who want to save some battery and/or network traffic, want to spped
up listviews, save ram and other good things:
look here:
Improving Layout Performance
Optimizing Battery Life
Sharing content between applications
i hope, this can someone help to understand what we can do to make things nice.
Hi all
I am developing an app in which I would like to allow user-generated content. Specifically, this will be a remote control application, and I would like people to be able to add custom layouts, capable of sending "events" through the app, but I am not sure how to do so.
There are a couple of ways I have been looking at. The first is using a WebView so that this content can be developed in HTML. This would be nice and easy from their point of view, but it does have it's downsides, especially where security is concerned. If I was to do this, I would want to bind a "send" Javascript interface to my app, but disallow any other Javascript (I do not, for example, want it to be able to relay the button presses to some other place). I'm not sure exactly how I could do this.
The second way I can see would be to use an XML file and build up the layout from that. Here, the only way I could see it to parse the XML file and programatically build the layout. This seems a lot of work, and I would rather avoid that.
A third way would be to import a layout purely as an image plus an XML file describing hot-spots for triggering events. This seems to have too many limitations.
The final option is to expose an interface to other apps, and allow users to build separate applications which hook in to provide these layouts. This seems a terrible approach for such a simple objective.
So, does anyone know of a simple way to do what I am after, or any comments on the options listed above? Has anyone done anything similar, or know of an open-source project which acheives something similar?
Thanks in advance
This is a thread made for learning c programming and making ourselves useful in this developing site and take part or help the developers for the making or the discovery of wonderful or let's say useful modifications
ANY HELP FROM ANY MEMBER IS APPRECIATED
whoever wants to learn and help others in developing is welcome . we want as many members as possible so friends please come learn and contribute ..... currently this thread is being hosted by:-
Senior Member badadroid lover;and
Member billpao
Please share your knowledge with all of us and try and learn more.... its an open thread.
introduction
Turbo C++ Integrated Development Environment
IDE is nothing but Integrated Development Environment in which one can develop, run, test and debug the application. The Turbo C++ IDE appears as shown in figure.
The C Developing Environment is a screen display with windows and pull-down menus. The program listing, error messages and other information are displayed in separate windows. The menus may be used to invoke all the operations necessary to develop the program, including editing, compiling, linking, and debugging and program execution. If the menu bar is inactive, it may be invoked by pressing the [F10] function key. To select different menu, move the highlight left or right with cursor (arrow) keys. You can also revoke the selection by pressing the key combination for the specific menu.
Invoking the Turbo C IDE
The default directory of Turbo C compiler is c:\tc\bin. So to invoke the IDE from the windows you need to double click the TC icon in the directory c:\tc\bin.
The alternate approach is that we can make a shortcut of tc.exe on the desktop.
Opening New Window in Turbo C
To type a program, you need to open an Edit Window. For this, open file menu and click “new”. A window will appear on the screen where the program may be typed.
Writing a Program in Turbo C
When the Edit window is active, the program may be typed. Use the certain key combinations to perform specific edit functions.
Saving a Program in Turbo C
To save the program, select save command from the file menu. This function can also be performed by pressing the [F2] button. A dialog box will appear asking for the path and name of the file.Provide an appropriate and unique file name. You can save the program after compiling too but saving it before compilation is more appropriate.
Making an Executable File in Turbo C
The source file is required to be turned into an executable file. This is called “Making” of the .exe file. The steps required to create an executable file are:
1. Create a source file, with a .c extension.
2. Compile the source code into a file with the .obj extension.
3. Link your .obj file with any needed libraries to produce an executable program
All the above steps can be done by using Run option from the menu bar or using key combination Ctrl+F9 (By this linking & compiling is done in one step).
Compiling and linking in the Turbo C IDE
In the Turbo C IDE, compiling and linking can be performed together in one step. There are two ways to do this: you can select Make EXE from the compile menu, or you can press the [F9] key
Correcting Errors in Turbo C
If the compiler recognizes some error, it will let you know through the Compiler window. You’ll see that the number of errors is not listed as 0, and the word “Error” appears instead of the word “Success” at the bottom of the window. The errors are to be removed by returning to the edit window. Usually these errors are a result of a typing mistake. The compiler will not only tell you what you did wrong, they’ll point you to the exact place in your code where you made the mistake.
Executing a Programs in Turbo C
If the program is compiled and linked without errors, the program is executed by selecting Run from the Run Menu or by pressing the [Ctrl+F9] key combination.
Exiting Turbo C IDE
An Edit window may be closed in a number of different ways. You can click on the small square in the upper left corner, you can select close from the window menu, or you can press the Alt+F3 combination. To exit from the IDE, select Exit from the File Menu or press Alt+X Combination.
here is the download link
I want to suggest some C programming books:
For completely starters:
C Programming A Modern Approach
Learn C The Hard Way
Deep C Secrets
For guys that have a few experience:
The C Programmin Language ( from the C editors )
C: A Reference Manual
The C Puzzle Book
---------- Post added at 10:51 PM ---------- Previous post was at 10:17 PM ----------
We have started a new C Team for starters. Anyone that want to learn C or know a few things for C can join here. We prefere users that want to contribute at badadroid project. If many members come I will make a private chat room fot the team that we will share our ideas,questions,problems etc. and we will talk of course.
The members at team now are:
billpao, badadroid lover , karimdag
If someone interests post it here or send me message!
Maybe 1 project to start...
Screenlock problem on Wave II...
Maybe minimum requirement, to know which files are involved from source code...
I have NOTHING to contribute, because no Programming skills...
Best Regards
I want to learn C too !
Sent from my GT-S8500 using xda app-developers app
adfree said:
Maybe 1 project to start...
Screenlock problem on Wave II...
Maybe minimum requirement, to know which files are involved from source code...
I have NOTHING to contribute, because no Programming skills...
Best Regards
Click to expand...
Click to collapse
Screen lockfix is really challenging for us!
karimdag said:
I want to learn C too !
Sent from my GT-S8500 using xda app-developers app
Click to expand...
Click to collapse
If you are going to start C I will put you on the team
---------- Post added 6th April 2013 at 12:05 AM ---------- Previous post was 5th April 2013 at 11:44 PM ----------
New member added karimdag !
badadroid lover said:
This is a thread made for learning c programming and making ourselves useful in this developing site and take part or help the developers for the making or the discovery of wonderful or let's say useful modifications
ANY HELP FROM ANY MEMBER IS APPRECIATED
whoever wants to learn and help others in developing is welcome . we want as many members as possible so friends please come learn and contribute ..... currently this thread is being hosted by:-
Senior Member ash009;
Member badadroid lover;and
Member billpao
Please share your knowledge with all of us and try and learn more.... its an open thread.
Click to expand...
Click to collapse
Seriously guys, I have been following especially the modem driver development for some time, and I can tell you it is not my missing experience in the c language that cause the lack of understanding of what is going on under the hood. It is hard for me to write this, but I would not recommend starting with c as a programming language at all (the void pointers still make me go crazy :]). The code has grown with the development and is in the current state, how should I put it, not very developer friendly.
You can hate me for that, but in my opinion there is no way on earth a beginner can contribute to the implementation without making it even less readable or transform it into a complete patchwork rug.
Don't get me wrong, I love your encouragement, but lets be realistic: without some kind of documentation only the contributers know what, how and why they do what they are doing.
Hats off to Volk, Rebellos and everyone involved!
DieterM75 said:
Seriously guys, I have been following especially the modem driver development for some time, and I can tell you it is not my missing experience in the c language that cause the lack of understanding of what is going on under the hood. It is hard for me to write this, but I would not recommend starting with c as a programming language at all (the void pointers still make me go crazy :]). The code has grown with the development and is in the current state, how should I put it, not very developer friendly.
You can hate me for that, but in my opinion there is no way on earth a beginner can contribute to the implementation without making it even less readable or transform it into a complete patchwork rug.
Don't get me wrong, I love your encouragement, but lets be realistic: without some kind of documentation only the contributers know what, how and why they do what they are doing.
Hats off to Volk, Rebellos and everyone involved!
Click to expand...
Click to collapse
Also mind haw grown ! Now we are able to do what ever we want to but of course we need to want to do what we do. And even if the first steps will be very hard i think all of us will do his best therefore learning C won't be used only in this project we will be able to use it in many others and even creating our own !
"If we want so we can"
Edit 2 : ''my..experience in the C Language" so this mean that you already learned it. So could you please help us by giving us some other refrences : Books, websites, videos..
Sent from my GT-S8500 using xda app-developers app
DieterM75 said:
Seriously guys, I have been following especially the modem driver development for some time, and I can tell you it is not my missing experience in the c language that cause the lack of understanding of what is going on under the hood. It is hard for me to write this, but I would not recommend starting with c as a programming language at all (the void pointers still make me go crazy :]). The code has grown with the development and is in the current state, how should I put it, not very developer friendly.
You can hate me for that, but in my opinion there is no way on earth a beginner can contribute to the implementation without making it even less readable or transform it into a complete patchwork rug.
Don't get me wrong, I love your encouragement, but lets be realistic: without some kind of documentation only the contributers know what, how and why they do what they are doing.
Hats off to Volk, Rebellos and everyone involved!
Click to expand...
Click to collapse
hey man everything doesn't happen in a shot every thing needs to get started and this is a starting as we might end up helping the devs..... btw our learning speed of course is pacing up... as we are working as a team...... and it would even be better if people (inc. you) would share whatever you know .... and also help devs to whichever extent....... we will do our best.... maybe you also will....i don't know.... i just know that is good to ...... and we are running on the right track......
adfree said:
Maybe 1 project to start...
Screenlock problem on Wave II...
Maybe minimum requirement, to know which files are involved from source code...
I have NOTHING to contribute, because no Programming skills...
Best Regards
Click to expand...
Click to collapse
there
DieterM75 said:
This should be the driver itself:
https://raw.github.com/Rebell/andro...ellybean/drivers/video/samsung/s3cfb_lg4573.c
I could also find some setup methods related to the display driver in the following module:
https://raw.github.com/Rebell/andro...e/jellybean/arch/arm/mach-s5pv210/mach-wave.c
Simply search for "S8530" and you will find pretty interesting parts
Just found another one:
https://raw.github.com/Rebell/andro...ean/arch/arm/mach-s5pv210/wave-panel-lg4573.c
Still no clue why gpios are set the way they are...
Click to expand...
Click to collapse
everyone check these :-
C Programming Tutorial for Beginners 1
C Programming Tutorial for Beginners 2 (Part 1): Using Variables With C
C Programming Tutorial for Beginners 2 (Part 2): Using Variables With C
C Programming Tutorial for Beginners 3 (Part 1): Programming in C with Strings and Char Data Type
C Programming Tutorial for Beginners 3 (Part 2): Programming in C with Strings and Char Data Type
C Programming Tutorial for Beginners 4 (Part 1): Programming in C with Conditionals: IF/ELSE/ELSE IF
C Programming Tutorial for Beginners 4 (Part 2): Programming with Conditionals: IF/ELSE/ELSE IF
next step
A Simple C Program
Every C program must have one special function main (). This is the point where execution begins when the program is running. We will see later that this does not have to be the first statement in the program, but it must exist as the entry point. The group of statements defining the main () enclosed in a pair of braces ({}) are executed sequentially. Each expression statement must end with a semicolon. The closing brace of the main function signals the end of the program. The main function can be located anywhere in the program but the general practice is to place it as the first function.
Here is an elementary C program.
main ()
{
}
There is no way to simplify this program, or to leave anything out. Unluckily, the program does not do anything. Following the "main" program name is a couple of parentheses, which are an indication to the compiler that this is a function. The 2 curly brackets { }, properly called braces, are used to specify the limits of the program itself. The actual program statements go between the 2 braces and in this case, there are no statements because the program does absolutely nothing. You will be able to compile and run this program, but since it has no executable statements, it does nothing. Keep in mind however, that it is a legal C program.
main ( ) function should return zero or one. Turbo C accepts both int and void main ( ) and Turbo C coders use both int and void main ( ) in their programs. But in my belief, void main ( ) is not a standard usage. The reason is, whenever a program gets executed it returns an integer to the OS. If it returns 'zero', the program is executed successfully. Otherwise it means the program has been ended with error. So main ( ) shouldn't be declared as void.d as void.
main( ) should be declared as
int main( )
{
……………..
……………..
return 0 ;
}
.For a much more interesting program, load the program
int main ()
{
printf (“Welcome to C language”);
return 0;
}
and display it on your monitor. It is same as the previous program except that it has one executable statement between the braces.
The executable statement is another function. Again, we won't care about what a function is, but only how to use this one. In order to output text to the monitor, it's placed within the function parentheses and bounded by quotes. The end result is that whatever is included between the quotes will be showed on the monitor when the program is run.
Notice the semi-colon; at the end of the line. C uses a semi-colon as a statement terminator, so semi-colon is required as a signal to the compiler that this line is complete. This program is also executable, so you'll be able to compile and run it to see if it does what you think it should. With some compilers, you may get an error message while compiling, indicating that the function printf () should have a prototype.
#include<stdio.h>
#include<conio.h>
int main ()
{
printf (“Welcome to C language”);
return 0;
}
Here you'll be able to see #include at the beginning of the program. It is a pre-processor directive. It's not a part of our program; it's an instruction to the compiler to make it do something. It says the C compiler to include the contents of a file, in this case the system file stdio.h. This is the name of the standard library definition file for all Standard Input Output. Your program will almost certainly want to send stuff to the screen and read things from the keyboard. stdio.h is the name of the file in which the functions that we want to use are defined. A function is simply a group of related statements that we can use later. Here the function we used is printf . To use printf correctly C needs to know what it looks like, i.e. what things it can work on and what value it returns. The actual code which performs the printf will be tied in later by the linker. Note that without the definition of what printf looks like the compiler makes a guess when it sees the use of it. This can lead to the call failing when the program runs, a common cause of programs crashing.
The <> characters around the name tell C to look in the system area for the file stdio.h. If I had given the name "abc.h" instead it would tell the compiler to look in the current directory. This means that I can arrange libraries of my own routines and use them in my programs.
Imagine you run above program and then change it and run it again you may find that the previous output is still stucked there itself, at this time clrscr(); would clear the previous screen.
One more thing to remember while using clrscr() is that it should be called only after the variable declaration, like
int p,q,r;
clrscr()
Here is an example of minimal C program that displays the string Welcome to C language (this famous example included in all languages moreover been done originally in C in 1978 from the creators of the language, Brian Kernighan and Dennis Ritchie) Example
#include<stdio.h>
#include<conio.h>
int main ()
{
clrscr();
printf (“Welcome to C language”);
return 0;
}
When you execute above program you won’t see ‘Welcome to C language’ on the console because the screen will just flash and go away .If you want to see the line you can use getch() function just below the printf() statement. Actually it waits until a key is pressed.
Identifiers
Identifiers are the names that are given to various program elements such as variables, symbolic constants and functions.Variable or function identifier that is called a symbolic constant name.
Identifier can be freely named, the following restrictions.
Alphanumeric characters ( a ~ z , A～Z , 0～9 ) and half underscore ( _ ) can only be used.
The first character of the first contain letters ( a ~ z , A～Z ) or half underscore ( _ ) can only be used.
Case is distinguishable. That is, word and WORD is recognized as a separate identifier.
Reserved words are not allowed. However, part of an identifier reserved words can be included.
Here are the rules you need to know:
1. Identifier name must be a sequence of letter and digits, and must begin with a letter.
2. The underscore character (‘_’) is considered as letter.
3. Names shouldn't be a keyword (such as int , float, if ,break, for etc)
4. Both upper-case letter and lower-case letter characters are allowed. However, they're not interchangeable.
5. No identifier may be keyword.
6. No special characters, such as semicolon,period,blank space, slash or comma are permitted
Examples of legal and illegal identifiers follow, first some legal identifiers:
float _number;
float a;
int this_is_a_very_detailed_name_for_an_identifier;
The following are illegal (it's your job to recognize why):
float :e;
float for;
float 9PI;
float .3.14;
float 7g;
Keywords
Keywords are standard identifiers that have standard predefined meaning in C. Keywords are all lowercase, since uppercase and lowercase characters are not equivalent it's possible to utilize an uppercase keyword as an identifier but it's not a good programming practice.
Points to remember
1. Keywords can be used only for their intended purpose.
2. Keywords can't be used as programmer defined identifier.
3. The keywords can't be used as names for variables.
The standard keywords are given below:
Data Types
C offers a standard, minimal set of basic data types. Sometimes these are called "primitive" types. A lot of complex data structures can be developed from these basic data types. The C language defines 4 fundamental data types:
character
integer
floating-point and
double floating-point
This data types are declared using the keywords char,int,float and double respectively. Typical memory requirements of the basic data types are given below
@Thread:
Good idea.
I recommend this tutorial - http://www.cprogramming.com/tutorial/c-tutorial.html
And of course http://www.google.com
To develop Android/Linux kernel you need... well - Linux host machine. For the begginers Ubuntu is good choice. Shell commands are google'able.
You also need knowledge about GIT. So http://try.github.com waits.
@adfree:
I concur that fixing Wave2 LCD wakeup would be good first "task".
@DieterM75:
I started C++ coding with practically falling into thing called "Open Tibia Server".
I started ARM assembler with creating FOTA bootloader.
Everything is for people, thing is I was spending up to 8-10hours daily when learning new things. To understand certain things there's just need to remember that it was all created by humans. Smart humans. And it has its technical limitations.
You are right about the files used
arch/arm/s5pv210/mach-wave.c <- Wave platform startup and operational code, putting it all together and loading drivers for most of the stuff onboard, there's general definition of platform data for LG4573, some GPIO config functions, etc etc.
arch/arm/s5pv210/wave-panel-lg4573.c <- more platform-dependent code, that's specifically LCD type identification routine and command sequences for certain LCD types (I can pull sequences for type 1 and 2 from bootloaders or APPS, though we haven't identified any devices actually using these typest)
drivers/video/samsung/s3cfb-lg4573.c <- platform-independent driver code for LG4573 IC
drivers/video/samsung/s3cfb.c <- platform-independent (at least in theory, there's ugly hack for S8500's AMOLED for eg. so this doesn't exactly follow the standards) code for CPU's framebuffer device.
There'll be also something in include/linux/lg4573.h or around I believe, like platform data definition etc.
What's to careful about - S3CFB is kinda "master" driver. During sleep it's first to put to sleep and it does invoke its "client" driver sleep function, that's LCD. It does also invoke some GPIO config stuff. So yeah - that's messy and not really transparent.
@badadroid lover:
Dude, don't attach images in BMP. This is just... Wrong, It's common sense to use JPG or PNG through internet.
Rebellos said:
@badadroid lover:
Dude, don't attach images in BMP. This is just... Wrong, It's common sense to use JPG or PNG through internet.
Click to expand...
Click to collapse
all right actually ummm... im sorry ..... ill use jpg now.....
Double
Double-precision floating point numbers are also numbers with a decimal point. We know that the float type can take large floating point numbers with a small degree of precision but the double-precision double type can hold even larger numbers with a higher degree of precision.
The sizes of the double types are as follows.
Type Bytes Minimal range
doubleprecision 8 IE-38 to IE+38 with 10 digit of precision
long double 8 IE-38 to IE+38 with 10 digit of precision
char
char is a special integer type designed for storing single characters. The integer value of a char corresponds to an ASCII character. E.g., a value of 65 corresponds to the letter A, 66 corresponds to B, 67 to C, and so on.
As in the table below, unsigned char permits values from 0 to 255, and signed char permits values from -127 (or -128) to 127. The char type is signed by default on some computers, but unsigned on others the sizes of the char types are as follows.
Type Bytes Minimal range
char 1 -127 to 127
unsigned char 1 0 to 255
signed char 1 -127 to 127
Float Floating point numbers are numbers with a decimal point. The float type can take large floating point numbers with a small degree of precision (Precision is simply the number of decimal places to which a number can be calculated with accuracy. If a number can be calculated to three decimal places, it is said to have three significant digits.)
Memory size : 4 bytes
Minimal range : IE-38 to IE+38 with six digit of precision
int
An integer is a whole number (a number without a fractional part). It can be positive or negative numbers like 1, -2, 3, etc., or zero.
The sizes of the integer variables depend on the hardware and operating system of the computer. On a typical 16-bit system, the sizes of the integer types are as follows.
TYPE
Bytes
Possible Values le Values
int
2 or 4
-32,767 to 32,767
unsigned int
2 or 4
0 to 65,535
signed int
2 or 4
-32,767 to 32,767
short int
2
-32,767 to 32,767
unsigned short int
2
0 to 65,535
signed short int
2
-32,767 to 32,767
long int
4
-2,147,483,647 to 2,147,483,647
signed long int
4
-2,147,483,647 to 2,147,483,647
unsigned long int
4
0 to 4,294,967,295
here is an awesome site i have been following:- http://www.cprogrammingexpert.com/
Even though this site is french I find it good.
http://www.siteduzero.com/
Hello.
I followed all the New Boston Android videos, did everything, understood everything.
I tried to create a basic RSS feed reader, in order to better incorporate some concepts I learned in the New Boston videos (http processing, xml processing, adapting the content to lists, custom lists, etc). When I got to pass the information from the http processed data to xml parser and the list, that's when I got too much confused and knew I didn't have enough knowledge.
Then I tried to do some "Shopping List Manager" (just like OI Shopping, a bit adapted more to my taste), in order to learn.
However, again, when I neededto pass information to other objects in other classes or something like that, I get confused and don't know what to do.
So I bought CommonsWare book, "The Busy Coder's Guide to Android", which I have the latest version (5.1) and I'm reading, but I don't like to advance when I don't fully understand something. This time I'm stuck on the Action Bar part, more precisely this one:
Code:
private void configureActionItem(Menu menu) {
EditText add=
(EditText)menu.findItem(R.id.add).getActionView()
.findViewById(R.id.title);
add.setOnEditorActionListener(this);
}
I know this will seem very basic to many of you, but I get really confused on all this calls, returning results and more calls.
I don't have a background on OOP, except when I worked with PHP frameworks like Symfony, I work usually with direct task programming (scripting, automation, etc), as I am a Linux System Administrator, so my code is mainly scripting and web interface building (Python, Shell Script, PHP, Javascript, etc).
Can anybody explain what can I do to better understand this? It's just lack of practice and in time I'll understand better? Is it OOP lack of knowledge/practice? Or is it Java lack of knowledge/practice?
Thanks a lot for all your help.
Maybe the best approach is to get some face time with a person who is more experienced and have him explain to you the concept you have trouble with while focusing on the parts you don't grasp. A real human has this flexibility to do a "targeted strike" unlike a tutorial or a book that has no idea where in particular the student may get confused.
For this particular issue, the issue can be summarized as follows. Let's say you have an object call a function:
Code:
orange.peel();
This should be relatively straightforward. The next level of complexity is the fact that obj is just a variable representing an object, and in fact we can substitute anything else that evaluates to an object (i.e.: after it runs, you end up with an object). For example these all are legal ways to call the method as long as types match:
Code:
(new Orange()).peel();
(shouldEatSmallerOrange ? smallerOrange : largerOrange).peel();
retrieveOrangeFromBox().peel();
The last line illustrates calling some other function that returns the object, which is then used to call a second function. The final step from here is to recognize that instead of a single retrieveOrangeFromBox() we can have a chain of functions, each of which returns an object that is used to call the next function in line. For example:
Code:
findCar().accessCarTrunk().unloadBoxFromTrunk().retrieveOrangeFromBox().peel();
The names are unnecessarily verbose to illustrate how functions and their results relate to each other.
OOP + Android system
You're not that clear as to exactly what you are having a problem with, but in general, it sounds like you need to get a java book and learn the basic concepts of classes and interfaces. Since you say you have a background in PHP you could probably go pretty far just by following the Java tutorials on the Sun website. I say java because that's the target language here, any book on OOP in any language would be adequate but learning java would give you the added ability to read other people's android code examples more easily.
After that, you can learn the Android framework. You develop in the Java language but you work within the android framework. What that means is that here, for example, the action bar is provided to you by the android system, and this callback is called by the system, so it is all set up for you. But to understand what is happening, you need to understand when the system calls this method and what it does. That is the framework.
So more specifically, how can you understand this code? This method is called from another method, onCreateOptionsMenu(). OnCreateOptionsMenu() is a method in the Activity class that is called automatically by the system at a specific time. You need to read about the Activity class and the Activity lifecycle on the android developers site. If you want your activity to provide an options menu, you create it in OnCreateOptionsMenu and return it, the system will handle it from there. So back to configureActionItem(Menu menu), here you are passing in the menu object, which contains MenuItem objects, which the system uses to populate the menu (either on the action bar, or when you hit the menu button, depending on the android version). Each MenuItem object has a view that is associated with it (usually created in an XML file).
One thing that may be hard to understand is that all these calls are chained, so if you don't know what they are returning you don't know where to look for help. It's easier if you separate the calls out. Here, the documentation is your friend. If you look at the Menu class on the android dev site, you see that findItem() returns a MenuItem. So then you look up MenuItem, and you see that getActionView() returns a View. Look at the View class, and you can see findViewById() returns another view (a sub-view that is contained within this view). so when you look at it all together, unchained:
Code:
private void configureActionItem(Menu menu) {
MenuItem mi = menu.findItem(R.id.add);
View parentView = mi.getActionView();
EditText add = (EditText)parentView.findViewById(R.id.title);
}
findViewById returns a View, but you know that the view known by the id R.id.title is an EditText view, and you want to use it as an EditText, so you have to cast the View to an EditText (which is a subclass of View) so that the compiler knows that it is an EditText type of view. That's what the (EditText) is doing in front of the findViewById call. To understand that you need to read about subclassing and strongly-typed programming languages. PHP is weakly-typed, so that might be new to you.
finally, you call setOnEditActionListener on the EditText. OnEditActionListener is an interface that you have implemented in this class. An interface defines a common set of methods that are guaranteed to be present in whichever class has implemented it. So when you set the OnEditActionListener to this, (this means the current instance of this class), the EditText will hold on to the "this" object and it knows that it can call a certain set of methods on it. What are those methods? look up the OnEditActionListener interface in the docs:
it only has one method,
Code:
public abstract boolean onEditorAction (TextView v, int actionId, KeyEvent event);
so somewhere in this class, you will have this method defined and this is where you put code that you want to run when the EditText triggers this action. I assume this get called when the user touches the EditText.
It's really not going to be easy to work with android if you don't have a basic knowledge of OOP, specifically classes, inheritance, and interfaces. Also, knowing how java implements these concepts will help a lot. Then you can use your book to learn the Android framework.
GreenTuxer said:
Hello.
I followed all the New Boston Android videos, did everything, understood everything.
I tried to create a basic RSS feed reader, in order to better incorporate some concepts I learned in the New Boston videos (http processing, xml processing, adapting the content to lists, custom lists, etc). When I got to pass the information from the http processed data to xml parser and the list, that's when I got too much confused and knew I didn't have enough knowledge.
Then I tried to do some "Shopping List Manager" (just like OI Shopping, a bit adapted more to my taste), in order to learn.
However, again, when I neededto pass information to other objects in other classes or something like that, I get confused and don't know what to do.
So I bought CommonsWare book, "The Busy Coder's Guide to Android", which I have the latest version (5.1) and I'm reading, but I don't like to advance when I don't fully understand something. This time I'm stuck on the Action Bar part, more precisely this one:
Code:
private void configureActionItem(Menu menu) {
EditText add=
(EditText)menu.findItem(R.id.add).getActionView()
.findViewById(R.id.title);
add.setOnEditorActionListener(this);
}
I know this will seem very basic to many of you, but I get really confused on all this calls, returning results and more calls.
I don't have a background on OOP, except when I worked with PHP frameworks like Symfony, I work usually with direct task programming (scripting, automation, etc), as I am a Linux System Administrator, so my code is mainly scripting and web interface building (Python, Shell Script, PHP, Javascript, etc).
Can anybody explain what can I do to better understand this? It's just lack of practice and in time I'll understand better? Is it OOP lack of knowledge/practice? Or is it Java lack of knowledge/practice?
Thanks a lot for all your help.
Click to expand...
Click to collapse
Thanks a lot for your help. I also think my issue is with OOP, but I needed the opinion of people with more knowledge.
I understand very well what you said about onCreateOptionsMenu(), why and when is called, Activity class, lifecycle, etc.
Those things I understand without any problem. I also understand the basics of OOP, but I don't know almost nothing about Interfaces and I don't have almost any experience with inheritance, although I understand it.
I think I'm just confused because I haven't worked very long with OOP. I just don't know if I should invest in something like reading and testing something like Thinking in Java, or just practice more and more Android Development.
This was released today but there does not appear to be much info on whether this is already in the wild. It would be almost undetectable.
Apparently it is possible to use statistical analysis of the size of the surfaceflinger off-screen buffer to predict with 90% accuracy what another app is doing. All an attacker needs is an application that runs in the background, and does not require any special permissions. Once it determines that a user is entering his password, for example, it can bring to the foreground an identical looking password dialog and capture the login data. Since the user expects this behavior, they may never notice.
So far all I could find is the actual paper:
cs.ucr.edu/~zhiyunq/pub/sec14_android_activity_inference.pdf
And some videos of a proof of concept have been posted:
f2bbs.com/thread/2234
The question is: has this been seen in the wild? Seems like a very serious threat without an obvious fix...