Wednesday, July 15, 2015
What is Google cloud Messaging
Thursday, July 9, 2015
What is Mono-based application
Successfully running a program requires that three things match:
CPU instruction set (Eg. x86 in your PC, ARM in your mobile phone, PowerPC in some Apple Macs, Java bytecode for Java Applets, CLI for ".Net"/Mono applications) Binary File Format (Eg. PE/COFF ".exe" for Microsoft Windows, .jar for Java Applets, PE32 ".exe", ELF on Unix/Linux) Application Programming Interface; (Eg. POSIX on Linux/Unix, Cocoa for Mac OSX, Win32 on Microsoft Windows, Base Class Library for ".Net"/Mono applications).
You can increase the chance of matching all three by having emulators/interpreters (for other CPU instruction sets), by having extra file loaders (for foreign file-formats), and having additional programming libraries providing more APIs.
Note also, that some processors can natively execute more than one instruction set; a PC quite often has x86 and amd64 instruction sets; an ARM processor can execute four: ARM32/Thumb/Java bytecode/ThumbEE. Some operating systems can provide more than one API natively too (Microsoft Windows provides Win32 and POSIX).
For everything else you need extra software. For running Java programs you need the three parts listed above to make it work: a Java Virtual Machine program to run the bytecode; a way of launching Java programs, and a Java Classlibrary for the programs to call. "Java" is a brandname here for several separate technologies originally developed by Sun, but to a user they are often downloaded as one.
The same applies for ".Net", which is a marketing brandname for several different technologies originally developed by Microsoft: The Common Language Run-time/Base Class Library (CLR) are the API; VES is the loader and Common Language Interface (CLI) is the instruction set.
You don't have to download those technologies from Microsoft, from Sun, or from Intel just because they originally invented something. AMD make processors compatible with Intel's standards; both Apache ("Harmony") and Google ("Android Dalvik") both make a Java-like suite; and Mono provides a CLR/CLI/VES suite. The important thing is that everyone uses the same standards, making them compatible. A DVD disc will play on any DVD player that meets the standard, and an HTML webpage will rendering in any Web Browser meeting the HTML standards.
Mono is a CLR/CLI/VES suite that can run on Mac OSX, MS Windows and Linux.
Wine is a Win32 API implementation that can run on Mac OSX, MS Windows and Linux.
You can run Mono on top of Wine, on top of any operating system.
You can run Wine on top of Qemu, on top of any CPU architecture.
So Mono makes CLR .exe applications run, and Wine makes Win32 .exe applications run. The only thing in common is that the filenames end in ".exe"; the contents are completely different and incompatible, so you need the right one.
Just like a Python interpreter will error when presented with Perl (and vis versa), a CLR interpreter will error when presented with x86+Win32, or JVM+Java bytecode. If you can post a link to the particular program that you're wanting to run, myself or somebody else should be able to tell you the exact instruction set, file format and API it was designed for, and what you need to install on Linux to run it. Hope that helps!
(Sometimes you might even need both. For example, the Openbve train simulator is C# and compiled to PE/COFF+CLI+CLR, but can optionally use C binary plugins compiled for PE/COFF+Win32+x86. In this case, you need a Win32 version of Mono under Wine. If the CPU architecture is also, different that would need emulating; so Mono under Wine under Qemu).
http://askubuntu.com/questions/31273/difference-between-wine-and-mono
Android in.NET Developers
Review in :http://www.codemag.com/Article/1308051
Mastery of mobile platforms makes you a better developer and can really give you more job opportunities. But let’s face it: The list of mobile platforms that offer more healthy prospects doesn’t yet include Windows Phone and Windows 8. Your outlook is just plain better if you can code for iOS or Android.
Your outlook is just plain better if you can code for iOS or Android.
As a seasoned .NET developer with a strong background in C#, what’s the easiest approach you can take to become a better mobile developer? In this article, I’ll show you the way to Android programming.
In many ways, the Android is an easy catch for .NET developers. First and foremost, the programming language is either C#, if you opt for writing apps through the Mono platform, or Java-a close relative to C#-if you take the classic route of the standard Android SDK. Second, you don’t need to buy a Mac in order to develop for Android. Whatever IDE you choose to use is available for Windows too. Finally, the user interface of Android apps is laid out using an XML schema that doesn’t look foreign to people who know XAML.
Compared to developing for iOS or even Windows Phone, Android programming is challenging for one notable reason: the huge number of significantly different devices that may be running your application. You can find Android on an $80 cell phone as well as on a high-end $500 smartphone. The difference in terms of power, battery, resources, and screen size can be huge. These variables add more work to the schedule and, even more than that, it adds forethought: you must plan your Android effort well for it to result in a success story.
Compared to developing for iOS or even Windows Phone, Android programming is challenging for one notable reason: the huge number of significantly different devices that may be running your application.
Far from the ultimate resource for all aspects of Android programming, this article aims modestly at providing practical information to get you started and creating functional test applications.
Options for Android Development
The primary approach to Android programming consists of downloading the Android SDK and writing your apps using the Java programming language. This approach guarantees the fastest and most compact apps, and this is the approach presented in the rest of this article.
If you’re a .NET developer, though, you might want to consider another option: Xamarin Studio from Xamarin. Note that Xamarin Studio (formerly MonoDroid) is a commercial product and may require you to buy a license. (For more information, have a look at http://www.xamarin.com.)
You can use the Xamarin Studio IDE (formerly MonoDevelop) on a Windows computer or you can install an extension to Visual Studio and keep using all of your favorite plug-ins.
An Android application built with Xamarin Studio executes within an instance of a Mono-based virtual computer. The Mono virtual computer, in turn, lives side-by-side with the Android’s virtual computer. To access native Android functionalities, you use a bunch of classes that look like classes in the .NET Framework except that they bind to the Android API under the hood.
To access native Android functionalities, you use a bunch of classes that look like classes in the .NET Framework except that they bind to the Android API under the hood.
The build of a Mono-based Android application passes through four steps: processing resources from Android resource files into .NET-compatible resource files; creation of the .NET code; processing of the .NET code to create Java wrappers; and final packaging of the Android executable.
In my opinion, the primary reason for using Mono for Android resides in the possibility of a quicker startup time as you can stay in Visual Studio and write in C#. However, the final application is a bit larger because of the extra Mono runtime. For an Android application, size may be an issue much more than for an iOS or Windows Phone application because of the wide range of different devices out there with very limited memory capabilities.
Another good reason for going Mono is that you can reuse some code across multiple mobile platforms. If you need to have an app for iOS, Android, and even Windows Phone, it’s likely that you can reuse some code.
Note, though, that this last point, while remarkable, is actually much less appealing than it may sound at first. The code you can reasonably reuse in a Mono-based set of mobile apps is only the business logic code you run on a device. The presentation layer of Mono-based Android applications must still closely reflect the philosophy and behavior of Android activities. You must know this in order to effectively write Mono-based Android applications. (And the same holds true for Mono-based iOS apps.) Making sense of the presentation logic of mobile platforms is the hardest part of writing mobile apps.
The code you can reasonably reuse in a Mono-based set of mobile apps is only the business logic code you run on a device.
Another option for writing Android applications is PhoneGap (see http://phonegap.com.) An app built against the PhoneGap framework is a classic client-side Web application made of HTML5 pages using CSS and JavaScript. You write and test the application within your favorite development platform, and using your favorite tools. For example, you can use Visual Studio or perhaps JetBrains’s WebStorm or any other text editor for the HTML pages and JavaScript logic. Once the Web core is ready, though, you have the problem of packaging that into a real Android application. You need an IDE for that like Eclipse or JetBrains’s IntelliJ IDEA. eOr, you can leverage the PhoneGap Build service (see http://build.phonegap.com) and upload your app to the service for packaging.
If you opt for doing it all by yourself, then you end up with a plain Android project in an IDE that supports Android development. Because the entire application is HTML and JavaScript, though, in this case, your exposure to Java and manifest files is minimal, although not null.
Monday, July 6, 2015
Android Tutorial for Beginners: Part 1
Following sites are useful
1.http://www.raywenderlich.com/78574/android-tutorial-for-beginners-part-1
2.http://www.sitepoint.com/12-android-tutorials-beginners/
Friday, July 3, 2015
Detection of water leaks and waterproofing services of roofs
It is normal that cracks are generated in the structures of our houses, apartments or offices, especially when the building is old and has little maintenance, often to correct them various techniques used to repair these imperfections. The cracks are generated due to prolonged moisture in the walls, by the time of the structures causes of earthquakes or large plant roots. Directly affect the appearance of the entire household coming to create big problems such as water seepage. Step number one for repair is visual inspection, if very deep is good to hire an expert. S i is superficial few tricks help correct the irregularities easily, among them are the following: 1. Assess the amount of cracks and depth 2. With the spatula, enlarge the crack and remove some paint to penetrate the product which will plug cracks. 3. Wipe off dirt and dust produced by enlarging the cracks 4. Prepare the dough product is plaster, putty or other product according to the type of roof. 5. Use the spatula and apply caulk cracks or other cracks tape product, with which the dough is prepared, it should be applied lengthwise. June 6. When the product is dry sand the surface, removing any dust Spread another layer of paint on the repaired area.
Thursday, January 7, 2010
Paint events & Properties in windows Application
With these events, why wouldn’t Microsoft combine Invalidate and Paint, so that you wouldn’t have to tell it to repaint, and then to force it to repaint? Painting is the slowest thing the OS does, so usually telling it to repaint, but not forcing it allows for the process to take place in the background
Assign an RGB color to a System.Drawing.Color object? Call the static method FromArgb of this class and pass it the RGB values.
ACCESS OF NON LOCAL NAMES in COMPILER DESIGN:
i. Non-local names
In a language with nested procedures (or blocks) and static scope (lexical scope), some names are neither local nor global, they are non-local names.
procedure A
real a;
procedure B
real b;
reference a; ß non-local
end B
end A;
Example: Non-local names in C
main () {
int a = 0, b=0; {
int b = 1; {
int a = 2;
print(a,b); }
{
int b = 3;
print(a,b); }
print(a,b);}
print(a,b); }
i. Block-level and Procedure-level ARs
• Each block can be considered as an in-line procedure without parameters. So we could create a new AR for each block. This is block-level AR and is very inefficient.
• In procedure-level AR method, AR is only used for a true procedure. The relative location of variables in individual blocks within a procedure can be computed and fixed at compile time.