使用C#开发移动应用：超越Windows Phone

5星 · 超过95%的资源需积分: 16 25 浏览量更新于2024-07-24 收藏 5.83MB PDF 举报

"Mobile Development With C#" 本书"Mobile Development With C#"主要探讨了如何使用C#语言进行跨平台的移动应用开发，不局限于Windows Phone，而是涵盖了更广泛的移动操作系统，如Android、iOS和可能的其他系统。作者Greg Shackles通过本书分享了他的专业知识和经验，帮助开发者扩展技能，构建能够在不同设备上运行的应用程序。在移动开发领域，C#是一种强大且灵活的语言，尤其因为.NET框架和Xamarin平台的兴起，使得C#成为开发跨平台移动应用的首选语言之一。Xamarin允许开发者使用C#编写原生的Android、iOS和Windows应用，同时利用共享代码库提高效率。书中的内容可能包括： 1. **C#基础**：介绍C#语言的基本语法，包括类、对象、接口、泛型、异常处理以及异步编程等概念，这些都是开发移动应用的基础。 2. **Xamarin环境搭建**：详述如何安装和配置Xamarin Studio或Visual Studio，以及如何设置模拟器或连接物理设备进行调试。 3. **UI设计**：讨论使用Xamarin.Forms创建用户界面的方法，以及如何实现响应式布局和平台特定的UI优化。 4. **数据持久化**：讲解如何使用SQLite数据库、XML或JSON文件存储应用程序数据，以及如何利用云服务进行数据同步。 5. **网络通信**：介绍网络请求的实现，包括HTTP请求、Web API集成以及使用RESTful服务交换数据。 6. **设备功能访问**：探讨如何访问手机的硬件特性，如GPS定位、摄像头、蓝牙、通知服务等。 7. **性能优化**：提供关于代码性能优化、内存管理以及电池寿命考虑的建议，以确保应用在不同设备上的表现。 8. **测试与调试**：讲述如何进行单元测试、集成测试以及性能测试，以及使用调试工具解决问题的方法。 9. **发布与分发**：指导如何准备应用发布，包括签名证书、应用商店提交流程以及后续的更新和维护。 10. **跨平台最佳实践**：分享如何最大化代码重用，同时保持平台特性的原生体验，以及如何处理跨平台兼容性问题。本书适合有一定C#基础，并希望进入移动开发领域的程序员阅读。无论是初学者还是经验丰富的开发者，都能从中获取有价值的见解和实用技巧，以提升他们的移动应用开发能力。通过深入学习和实践，读者将能够利用C#构建出高效、稳定且具有吸引力的移动应用，覆盖全球各地的用户。

Android

Since Google purchased it in 2005 and began releasing versions in 2008, Android has

taken the smartphone market by storm. Just a few years and numerous versions after

its initial release, as of February 2012, Android accounts for just over 50% of the US

smartphone market, a number that continues to climb every month (http://www.com

score.com/Press_Events/Press_Releases/2012/4/comScore_Reports_February_2012_U

.S._Mobile_Subscriber_Market_Share). Most of Android is open source and licensed in

a way that gives hardware vendors a lot of flexibility, so the ecosystem of Android

phones is very diverse. Because of that flexibility, many vendors make significant

changes to the versions of Android that ship on their devices, so very few devices are

actually running a stock version of the operating system. With the release of Honey-

comb, Android has also started to stake its claim in the tablet market as well. Addi-

tionally, Android can be found in Google’s television platform, Google TV, as well

devices such as Barnes & Noble’s Nook Color and Amazon’s Kindle Fire, which bring

the richness of tablets to the world of e-readers. Ice Cream Sandwich, the version of

Android following Honeycomb, aims to help bridge the growing divide between An-

droid smartphones and tablets.

Windows Phone

In 2010, Microsoft released Windows Phone 7, which marked a long-overdue shift

away from its legacy Windows Mobile platform that had long since stagnated. The user

interface in Windows Phone 7, dubbed Metro, is decidedly unlike the approach taken

by both iOS and Android. A strong emphasis is placed on simplicity, typography, and

expansive interfaces that aim to provide a sense of depth and a natural user experience.

Device vendors are given a small amount of freedom in designing their devices, but

Microsoft maintains a strict set of requirements they have to meet in order to ensure

stability and quality, as well as avoid some of the fragmentation problems seen in the

Android realm. While the platform is still in the very early stages of its life, Microsoft

seems dedicated to pushing the platform forward to try and gain back some of the

market share the company has lost over the years. In late 2011, Microsoft shipped the

Windows Phone 7.5 update, codenamed Mango, which started to bring in many fea-

tures missing from the first releases, such as local databases and camera access.

Write Once, Run Anywhere

iOS, Android, and Windows Phone, despite the fact that they are all mobile platforms,

have very distinct ways of doing things and their own required languages in which to

do them. iOS applications are written in Objective-C, while Android makes use of Java.

Windows Phone leverages the .NET Framework, where the primary languages are C#

and Visual Basic .NET. You can also use C and C++ on iOS and Android, but they are

not currently supported on Windows Phone (see Table 1-1). As developers, we dread

2 | Chapter 1: Surveying the Landscape

the idea of having to repeat all of our work three times in three different programming

languages. Aside from the upfront overhead of doing the work three times, bug fixes

found later on will also likely have to be fixed three times. For any non-trivial

application, the technical debt can add up quickly, so the natural response is to seek

out some sort of cross-platform solution to minimize the cost of building and main-

taining applications for these devices.

Table 1-1. Native platform languages

iOS Android Windows Phone

C / C++ X X

Objective-C X

Java X

C# X

Visual Basic .NET X

The promise of a “write once, run anywhere” solution is nothing new in the develop-

ment world. It tends to come around whenever there’s a need to publish applications

on multiple platforms, whether on the desktop or on mobile devices. The mantra was

originally coined by Sun when it was pushing for Java to be the unifying language for

all platforms and devices. The concept is certainly not unique to Java, though, nor was

that the first time such a solution was proposed.

It has a natural appeal to us as developers. Who wouldn’t want a silver bullet like that

at our disposal? We could write everything once, get it just the way we want it, and

then instantly be able to target users on all platforms. Unfortunately, things that seem

too good to be true often are; there’s a reason why Java, over a decade and a half into

its life, has yet to become the common language for developing cross-platform desktop

applications. I think Nat Friedman, CEO of Xamarin, put it best in an interview he did

on the .NET Rocks! podcast:

“‘Write once, run anywhere perfectly’ is a unicorn.”

Now, let me take a step back for just a moment to provide some clarification here. I

don’t intend for anything in this chapter, or this book for that matter, to be taken as a

slight against frameworks that decided to take this approach to solving the problem.

The silver bullet trap works in both directions. No matter the context, there is never a

solution so perfect that it solves all problems. Instead, what I will outline in this book

is meant to demonstrate only one approach to solving things. It’s another set of tools

for your developer tool belt.

Having said that, let’s take a moment to think about who stands to benefit the most

from the “write once, run anywhere” method. You could make the argument that the

user benefits from you being quicker to market or supporting his platform, and though

there is some legitimacy to that, I would tend to disagree. Instead, when all is said and

done, it is we, the developers, who really benefit by cutting down the amount of time

Write Once, Run Anywhere | 3

it takes to write and publish our applications. However, this reduced development time

often involves making concessions that sacrifice user experience. Each platform has its

own hardware configurations, with varying screen sizes, resolutions, and buttons. Each

has its own set of user interaction metaphors and guidelines for how an application

should look and behave. In order for your application to look and feel native, it should

act like the other applications on that platform.

Writing to the lowest common denominator can end up making your application feel

foreign to all of them. Applications on Windows Phone are designed to look and behave

differently than those on iOS, and that is something that should be embraced rather

than glossed over or abstracted away. The experience you present to your users should

be the primary concern when designing your application’s interface. Ultimately, that

is what will set your application apart from others who take shortcuts along the way.

By now, you’re probably thinking to yourself, “So if I’m not writing in the platform’s

native language, and I’m not leveraging one of these cross-platform frameworks, how

do you expect me to write my applications?”

An Alternative Approach

What I am going to propose is an alternative approach where you can leverage the

power of the .NET Framework, along with the powerful C# language, across all three

platforms. While this may sound similar to “write once, run anywhere,” the key dif-

ference is that C# and the Base Class Libraries are used as a universal language and

library where the device-specific and user interface-specific elements are not abstracted,

but are instead exposed to developers. This means that developers build native appli-

cations using three different user interface programming models, one for each platform,

while using C# across the board.

As mentioned earlier, .NET is exposed natively on Windows Phone, so there’s no fric-

tion there. However, we know that on both iOS and Android it is not, so how can we

make this work? To help bridge this gap, a company named Xamarin has created two

products, MonoTouch and Mono for Android. We will explore these products in more

depth in later chapters, but the elevator pitch is that they allow for writing native

applications in C# (see Table 1-2), providing bindings to the platform’s native libraries

and toolkits so that you’re targeting the same classes you would in Objective-C for iOS

or Java for Android. Because you’re working against the platform’s native user interface

toolkits, you don’t need to worry about how to make your application look and feel

native to the platform, since it already is.

Table 1-2. Native platform languages with Mono tools

iOS Android Windows Phone

C / C++ X X

Objective-C X

4 | Chapter 1: Surveying the Landscape

iOS Android Windows Phone

Java X

C# X X X

Visual Basic .NET X

Apple is known for being strict about what gets into the App Store, so

you might be wondering whether it will only accept applications written

natively in Objective-C. There are actually thousands of MonoTouch

applications in the store. In fact, iCircuit, a MonoTouch application,

was shipped with their demo iPad 2 units that were sent out to stores.

As the names imply, MonoTouch and Mono for Android expose .NET on iOS and

Android by leveraging Mono, an open-source, cross-platform implementation of the

Common Language Infrastructure (CLI), an ISO standard that describes the virtual

execution environment that is used by C#. Despite the fact that they are commercial

products, both offer free evaluation versions that do not expire, and allow you to deploy

to the iOS simulator or the Android emulator. There is no risk in taking them out for

a spin. In the next chapter, we will explore how to get started with these tools, and

build your first application along the way.

Apple and Google release new versions regularly, so you might be won-

dering

what that means for you if you’re using MonoTouch or Mono

for Android. Generally, there is no waiting period here, as both products

track the beta programs for iOS and Android. For example, MonoTouch

typically releases the bindings for a new operating system within 24

hours of the official Apple release. In addition to the quick release cycle,

Xamarin offers first-class support for its products, providing prompt

responses through mailing lists and IRC, and maintaining thorough,

user-friendly documentation. Even outside of Xamarin, the Mono com-

munity in general is very active and helpful as well. You can find

information about the company and products at http://www.xamarin

.com/.

If you’re already a .NET developer, you can immediately hit the ground running, still

having the familiar namespaces and classes in the Base Class Library at your disposal.

Since the Mono Framework is being used to run your code, you don’t need to worry

about whether Objective-C or Java implements a particular C# feature you want to

use. That means you get things like generics, LINQ to Objects, LINQ to XML, events,

lambda expressions, reflection, garbage collection, thread pooling, and asynchronous

programming features. Taking things even further, you can often leverage many exist-

ing third-party .NET libraries in your applications as well. You can turn your focus

An Alternative Approach | 5

towards solving the business problem at hand instead of learning and fighting yet

another set of new languages.

As great as this is, the bigger win with this approach is the ability to share a large

percentage of your core application code across all platforms. The key to making the

most out of this is to structure your applications in such a way that you extract your

core business logic into a separate layer, independent of any particular user interface,

and reference that across platforms. By doing so, each application essentially becomes

a native user interface layer on top of that shared layer, so you get all the benefits of a

native user experience without having to rewrite the application’s main functionality

every time (see Table 1-3). In Chapter 3, we will explore some techniques available to

help keep as much code as possible in this shared layer and maximize code reuse across

platforms.

Table 1-3. Application layers

iOS Android Windows Phone

Runtime Mono Mono .NET

Business logic C# C# C#

User interface MonoTouch Mono for Android Silverlight

The classes and methods exposed by a framework make up what is referred to as its

profile. The .NET profile exposed by both MonoTouch and Mono for Android is based

on the Mono Mobile profile. The mobile profile is a version of the .NET 4.0 API that

has some of the desktop and server features removed for the sake of running on small

embedded devices, such as the System.Configuration namespace. This profile is very

similar to the core of Silverlight, which is also a subset of the full .NET profile for the

same reasons. Since Windows Phone is also based on Silverlight, there is a large amount

of overlap between all three of these profiles, meaning that non-user interface code you

write for one platform is very likely to be compatible with the other two.

Technically, the Windows Phone platform supports developing appli-

cations

using both the Silverlight and XNA frameworks. Since XNA is

more suited for game development, this book will focus on building

applications with Silverlight. By definition, games define their own user

interfaces, so not all of the problems outlined earlier with regards to

providing a quality cross-platform user experience will necessarily apply

when developing games.

The MonoGame project provides an XNA 2D implementation that runs

on both MonoTouch and Mono for Android. This is a third-party com-

munity project that is continuously evolving. More information about

the MonoGame project can be found at

http://github.com/mono/MonoGame.

6 | Chapter 1: Surveying the Landscape

剩余171页未读，继续阅读

ystlife

粉丝: 1
资源: 2

使用C#开发移动应用：超越Windows Phone

C#移动开发 [Mobile Development with C#]

Mobile Development with C#.

Mobile.Development

Learning to Master Cross-Platform Mobile Development with Xamarin（吾乐吧软件站分享）

Packt.iOS Development with Xamarin Cookbook.2014.pdf

Windows 10 Development with XAML and C 7, 2nd Edi.pdf

Creating mobile apps with xamarin.forms preview edition 2

Xamarin Mobile Application Development(Apress,2015)

Xamarin Mobile Application Development for Android(epub)

Xamarin with Visual Studio,C# EPUB

最新资源