Building mobile applications can be as easy as opening up Visual Studio, throwing something together, doing a quick bit of testing, and submitting to an App Store – all done in an afternoon.Or it can be an extremely involved process that involves rigorous up-front design, usability testing, QA testing on thousands of devices, a full beta lifecycle, and then deployment a number of different ways.
In this document, we’re going to take a thorough introductory examination of building mobile applications, including:
Process– The process of software development is called the Software Development Lifecycle (SDLC).We’ll examine all phases of the SDLC with respect to mobile application development, including: Inception, Design, Development, Stabilization, Deployment, and Maintenance.
Considerations– There are a number of considerations when building mobile applications, especially in contrast to traditional web or desktop applications.We’ll examine these considerations and how they affect mobile development.
This document is intended to answer fundamental questions about mobile app development, for new and experienced application developers alike.It takes a fairly comprehensive approach to introducing most of the concepts you’ll run into during the entire Software Development Lifecycle (SDLC).However, this document may not be for everyone, if you’re itching to just start building applications, we recommend jumping ahead to theIntroduction to Mobile Developmentguide and then coming back to this document later.
Mobile development software lifecycle
The lifecycle of mobile development is largely no different than the SDLC for web or desktop applications.As with those, there are usually 5 major portions of the process:
Inception– All apps start with an idea.That idea is usually refined into a solid basis for an application.
Design– The design phase consists of defining the app’s User Experience (UX) such as what the general layout is, how it works, etc., as well as turning that UX into a proper User Interface (UI) design, usually with the help of a graphic designer.
Development– Usually the most resource intensive phase, this is the actual building of the application.
Stabilization– When development is far enough along, QA usually begins to test the application and bugs are fixed.Often times an application will go into a limited beta phase in which a wider user audience is given a chance to use it and provide feedback and inform changes.
Deployment
Often many of these pieces are overlapped, for example, it’s common for development to be going on while the UI is being finalized, and it may even inform the UI design.Additionally, an application may be going into a stabilization phase at the same that new features are being added to a new version.
Furthermore, these phases can be used in any number of SDLC methodologies such as Agile, Spiral, Waterfall, etc.
Each of the these phases will be explained in more detail by the following sections.
Inception
The ubiquity and level of interaction people have with mobile devices means that nearly everyone has an idea for a mobile app.Mobile devices open up a whole new way to interact with computing, the web, and even corporate infrastructure.
The inception stage is all about defining and refining the idea for an app.To create a successful app, it’s important to ask some fundamental questions.Here are some things to consider before publishing an app in one of the public App Stores:
Competitive Advantage– Are there similar apps out there already?If so, how does this application differentiate from others?
For apps that will be distributed in an Enterprise:
Infrastructure Integration– What existing infrastructure will it integrate with or extend?
Additionally, apps should be evaluated in the context of the mobile form factor:
Value– What value does this app bring users?How will they use it?
Form/Mobility– How will this app work in a mobile form factor?How can I add value using mobile technologies such as location awareness, the camera, etc.?
To help with designing the functionality of an app, it can be useful to define Actors andUse Cases.Actors are roles within an application and are often users.Use cases are typically actions or intents.
For instance, a task tracking application might have two Actors:UserandFriend.A User mightCreate a Task, andShare a Taskwith a Friend.In this case, creating a task and sharing a task are two distinct use cases that, in tandem with the Actors, will inform what screens you’ll need to build, as well as what business entities and logic will need to be developed.
Once an appropriate number of use cases and actors has been captured, it’s much easier to begin designing an application.Development can then focus on how to create the app, rather than what the app is or should do.
Designing mobile applications
Once the features and functionality of the app have been determined, the next step is start trying to solve the User Experience or UX.
UX design
UX is usually done via wireframes or mockups using one of the manydesign toolkits.UX mockups allow the UX to be designed without having to worry about the actual UI design:
When creating UX mockups, it’s important to consider the interface guidelines for the various platforms that the app will target.The app should "feel at home" on each platform.The official design guidelines for each platform are:
For example, each app has a metaphor for switching between sections in an application.iOS uses a tab bar at the bottom of the screen, Android uses a tab bar at the top of the screen, and UWP uses thePivot or tabview.
Additionally, the hardware itself also dictates UX decisions.For example, iOS devices have no physicalbackbutton, and therefore introduce the Navigation Controller metaphor:
Furthermore, form factor also influences UX decisions.A tablet has far more real estate, and so can display more information.Often what needs multiple screens on a phone is compressed into one for a tablet:
And due to the myriad of form factors out there, there are often mid-size form factors (somewhere between a phone and a tablet) that you may also want to target.
User interface (UI) design
Once the UX is determined, the next step is to create the UI design.While UX is typically just black and white mockups, the UI Design phase is where colors, graphics, etc., are introduced and finalized.Spending time on good UI design is important and generally, the most popular apps have a professional design.
As with UX, it’s important to understand that each platform has it’s own design language, so a well-designed application may still look different on each platform:
Development
The development phase usually starts very early.In fact, once an idea has some maturation in the conceptual/inspiration phase, often a working prototype is developed that validates functionality, assumptions, and helps to give an understanding of the scope of the work.
In the rest of the tutorials, we’ll focus largely on the development phase.
Stabilization
Stabilization is the process of working out the bugs in your app.Not just from a functional standpoint, e.g.: “It crashes when I click this button,” but also Usability and Performance.It’s best to start stabilization very early within the development process so that course corrections can occur before they become costly.Typically, applications go intoPrototype,Alpha,Beta, andRelease Candidatestages.Different people define these differently, but they generally follow the following pattern:
Prototype– The app is still in proof-of-concept phase and only core functionality, or specific parts of the application are working.Major bugs are present.
Alpha– Core functionality is generally code-complete (built, but not fully tested).Major bugs are still present, outlying functionality may still not be present.
Beta– Most functionality is now complete and has had at least light testing and bug fixing.Major known issues may still be present.
Release Candidate– All functionality is complete and tested.Barring new bugs, the app is a candidate for release to the wild.
It’s never too early to begin testing an application.For example, if a major issue is found in the prototype stage, the UX of the app can still be modified to accommodate it.If a performance issue is found in the alpha stage, it’s early enough to modify the architecture before a lot of code has been built on top of false assumptions.
Typically, as an application moves further along in the lifecycle, it’s opened to more people to try it out, test it, provide feedback, etc. For instance, prototype applications may only be shown or made available to key stakeholders, whereas release candidate applications may be distributed to customers that sign up for early access.
For early testing and deployment to relatively few devices, usually deploying straight from a development machine is sufficient.However, as the audience widens, this can quickly become cumbersome.As such, there are a number of test deployment options out there that make this process much easier by allowing you to invite people to a testing pool, release builds over the web, and provide tools that allow for user feedback.
For testing and deployment, you can useApp Centerto continuously build, test, release, and monitor apps.
Distribution
Once the application has been stabilized, it’s time to get it out into the wild.There are a number of different distribution options, depending on the platform.
iOS
Xamarin.iOS and Objective-C apps are distributed in exactly the same way:
Apple App Store– Apple’s App Store is a globally available online application repository that is built into Mac OS X via iTunes.It’s by far the most popular distribution method for applications and it allows developers to market and distribute their apps online with very little effort.
In-House Deployment– In-House deployment is meant for internal distribution of corporate applications that aren’t available publicly via the App Store.
Ad-Hoc Deployment– Ad-hoc deployment is intended primarily for development and testing and allows you to deploy to a limited number of properly provisioned devices.When you deploy to a device via Xcode or Visual Studio for Mac, it is known as ad-hoc deployment.
Android
All Android applications must be signed before being distributed.Developers sign their applications by using their own certificate protected by a private key.This certificate can provide a chain of authenticity that ties an application developer to the applications that developer has built and released.It must be noted that while a development certificate for Android can be signed by a recognized certificate authority, most developers do not opt to utilize these services, and self-sign their certificates.The main purpose for certificates is to differentiate between different developers and applications.Android uses this information to assist with enforcement of delegation of permissions between applications and components running within the Android OS.
Unlike other popular mobile platforms, Android takes a very open approach to app distribution.Devices are not locked to a single, approved app store.Instead, anyone is free to create an app store, and most Android phones allow apps to be installed from these third party stores.
This allows developers a potentially larger yet more complex distribution channel for their applications.Google Playis Google’s official app store, but there are many others.A few popular ones are:
UWP applications are distributed to users via the Microsoft Store.Developers submit their apps for approval, after which they appear in the Store.For more information on publishing Windows apps, see UWP'sPublishdocumentation.
Mobile development considerations
While developing mobile applications isn’t fundamentally different that traditional web/desktop development in terms of process or architecture, there are some considerations to be aware of.
Common considerations
Multitasking
There are two significant challenges to multitasking (having multiple applications running at once) on a mobile device.First, given the limited screen real estate, it is difficult to display multiple applications simultaneously.Therefore, on mobile devices only one app can be in the foreground at one time.Second, having multiple applications open and performing tasks can quickly use up battery power.
Each platform handles multitasking differently, which we’ll explore in a bit.
Form factor
Mobile devices generally fall into two categories, phones and tablets, with a few crossover devices in between.Developing for these form factors is generally very similar, however, designing applications for them can be very different.Phones have very limited screen space, and tablets, while bigger, are still mobile devices with less screen space than even most laptops.Because of this, mobile platform UI controls have been designed specifically to be effective on smaller form factors.
Device and operating system fragmentation
It’s important to take into account different devices throughout the entire software development lifecycle:
Conceptualization and Planning– Keep in mind that hardware and features will vary from device to device, an application that relies on certain features may not work properly on certain devices.For example, not all devices have cameras, so if you’re building a video messaging application, some devices may be able to play videos, but not take them.
Design– When designing an application’s User Experience (UX), pay attention to the different screen ratios and sizes across devices.Additionally, when designing an application’s User Interface (UI), different screen resolutions should be considered.
Development– When using a feature from code, the presence of that feature should always be tested first.For example, before using a device feature, such as a camera, always query the OS for the presence of that feature first.Then, when initializing the feature/device, make sure to request currently supported from the OS about that device and then use those configuration settings.
Testing– It’s incredibly important to test the application early and often on actual devices.Even devices with the same hardware specs can vary widely in their behavior.
Limited resources
Mobile devices get more and more powerful all the time, but they are still mobile devices that have limited capabilities in comparison to desktop or notebook computers.For instance, desktop developers generally don’t worry about memory capacities; they’re used to having both physical and virtual memory in copious quantities, whereas on mobile devices you can quickly consume all available memory just by loading a handful of high-quality pictures.
Additionally, processor-intensive applications such as games or text recognition can really tax the mobile CPU and adversely affect device performance.
Because of considerations like these, it’s important to code smartly and to deploy early and often to actual devices to validate responsiveness.
iOS considerations
Multitasking
Multitasking is very tightly controlled in iOS, and there are a number of rules and behaviors that your application must conform to when another application comes to the foreground, otherwise your application will be terminated by iOS.
Device-specific resources
Within a particular form factor, hardware can vary greatly between different models.For instance, some devices have a rear-facing camera, some also have a front-facing camera, and some have none.
Some older devices (iPhone 3G and older) don’t even allow multitasking.
Because of these differences between device models, it’s important to check for the presence of a feature before attempting to use it.
OS specific constraints
To make sure that applications are responsive and secure, iOS enforces a number of rules that applications must abide by.In addition to the rules regarding multitasking, there are a number of event methods out of which your app must return in a certain amount of time, otherwise it will get terminated by iOS.
Also worth noting, apps run in what’s known as a Sandbox, an environment that enforces security constraints that restrict what your app can access.For instance, an app can read from and write to its own directory, but if it attempts to write to another app directory, it will be terminated.
Android considerations
Multitasking
Multitasking in Android has two components; the first is the activity lifecycle.Each screen in an Android application is represented by an Activity, and there is a specific set of events that occur when an application is placed in the background or comes to the foreground.Applications must adhere to this lifecycle to create responsive, well-behaved applications.For more information, see theActivity Lifecycleguide.
The second component to multitasking in Android is the use of Services.Services are long-running processes that exist independent of an application and are used to execute processes while the application is in the background.For more information see theCreating Servicesguide.
Many devices and many form factors
Google doesn’t impose any limits on which devices can run the Android OS.This open paradigm results in a product environment populated by a myriad of different devices with very different hardware, screen resolutions and ratios, device features, and capabilities.
Because of the extreme fragmentation of Android devices, most people choose the most popular 5 or 6 devices to design and test for, and prioritize those.
Security considerations
Applications in the Android OS all run under a distinct, isolated identity with limited permissions.By default, applications can do very little.For example, without special permissions, an application cannot send a text message, determine the phone state, or even access the Internet!To access these features, applications must specify in their application manifest file which permissions they would like, and when they’re being installed; the OS reads those permissions, notifies the user that the application is requesting those permissions, and then allows the user to continue or cancel the installation.This is an essential step in the Android distribution model, because of the open application store model, since applications are not curated the way they are for iOS, for instance.For a list of application permissions, see theManifest Permissionsreference article in the Android Documentation.
Windows considerations
Multitasking
Multitasking in UWP has two parts: the lifecycle for pages and applications, and background processes.Each screen in an application is an instance of a Page class, which has events associated with being made active or inactive (with special rules for handling the inactive state, or being “tombstoned”).
The second part is providing background agents for processing tasks even when the application is not running in the foreground.
Device capabilities
Although UWP hardware is fairly homogeneous, there are still components that are optional and therefore require special considering while coding.Optional hardware capabilities include the camera, compass, and gyroscope.There is also a special class of low-memory (256MB) that requires special consideration, or developers can opt-out of low-memory support.
Security considerations
For information on important security considerations in UWP, refer to theSecuritydocumentation.
Summary
This guide gave an introduction to the SDLC as it relates to mobile development.It introduced general considerations for building mobile applications and examined a number of platform-specific considerations including design, testing, and deployment.
모바일 애플리케이션 빌드는 Visual Studio를 열고, 함께 준비하고, 신속히 테스트하며 앱 스토어에 제출하는 것처럼 손쉽게 수행할 수 있습니다. 모든 작업이 그 날 완료됩니다.또는 엄격한 사전 설계, 유용성 테스트, 수천 대의 디바이스에서 QA 테스트, 전체 베타 주기 및 여러 가지 다른 방식의 배포가 포함된 매우 복잡한 프로세스일 수 있습니다.
이 문서에서는 다음을 포함하여 모바일 애플리케이션 빌드에 대한 소개를 자세히 살펴보겠습니다.
프로세스- 소프트웨어 개발 프로세스를 SDLC(소프트웨어 개발 수명 주기)라고합니다.다음과 같은 모바일 애플리케이션 개발에 관한 SDLC의 모든 단계를 살펴보겠습니다. 개시, 디자인, 개발, 안정화, 배포 및 유지 관리.
고려 사항– 특히, 기존 웹 또는 데스크톱 애플리케이션과 달리, 모바일 애플리케이션을 빌드할 때는 여러 가지 고려 사항이 있습니다.이러한 고려 사항과 이러한 고려 사항이 모바일 개발에 주는 영향에 대해 살펴 보겠습니다.
이 문서는 초급 및 고급 애플리케이션 개발자 모두를 대상으로 모바일 앱 개발에 대한 기본적인 질문에 답하기 위해 작성되었습니다.전체 SDLC(소프트웨어 개발 수명 주기) 중에 마주치는 대부분의 개념을 상당히 포괄적인 방식으로 소개합니다.그러나 이 문서가 모든 사람에게 적절한 것은 아닙니다. 바로 애플리케이션 빌드를 시작하고 싶다면모바일 개발 소개가이드로 이동한 다음, 나중에 이 문서를 다시 살펴보는 것이 좋습니다.
모바일 개발 소프트웨어 수명 주기
모바일 개발의 수명 주기는 웹 또는 데스크톱 애플리케이션의 SDLC와 크게 다르지 않습니다.마찬가지로, 5가지의 프로세스 주요 부분으로 구성됩니다.
개시– 모든 앱이 이 개념으로 시작됩니다.이 개념은 일반적으로 애플리케이션의 견고한 기반으로 구체화됩니다.
설계– 설계 단계는 일반적인 레이아웃이 무엇인지, 어떻게 작동하는지 등과 같은 앱의 UX(사용자 경험)를 정의하고 일반적으로 그래픽 디자이너를 활용해 UX를 적절한 UI(사용자 인터페이스) 디자인으로 바꾸는 것으로 구성됩니다.
개발– 일반적으로 리소스를 가장 많이 사용하는 단계이며 애플리케이션을 실제 빌드합니다.
안정화– 개발이 충분히 진행되면 일반적으로 QA를 통해 애플리케이션을 테스트하고 버그를 수정합니다.종종 애플리케이션은 제한된 베타 단계로 진행되며 이 단계에서 보다 광범위한 대상 사용자에게 애플리케이션을 사용하고 피드백을 제공하며 변경 내용을 알릴 기회가 주어집니다.
배포
이러한 단계는 많은 부분이 겹칩니다. 예를 들어, UI가 완료되는 동안 개발이 진행되는 것이 일반적이며 UI 디자인에 정보를 제공할 수도 있습니다.또한 애플리케이션은 새로운 기능이 새로운 버전에 추가되는 것과 동시에 안정화 단계에 들어갈 수 있습니다.
이러한 단계는 애자일(Agile), 나선형(Spiral), 폭포수(Waterfall) 등과 같은 다양한 SDLC 방법론에서도 사용할 수 있습니다.
각 단계는 다음 섹션에 서보다 자세히 설명합니다.
개시
모바일 디바이스를 보유하고 있는 사람의 보편화와 상호 작용 수준을 보면, 거의 모든 사람이 모바일 앱에 대한 개념이 있음을 알 수 있습니다.모바일 디바이스는 컴퓨팅, 웹, 심지어 기업 인프라와도 상호 작용할 수 있는 완전히 새로운 방식입니다.
개시 단계는 앱에 대한 개념을 정의 및 구체화하는 것입니다.성공적인 앱을 만들려면 몇 가지 기본적인 질문을 하는 것이 중요합니다.다음은 앱을 공개 앱 스토어 중 하나에 게시하기 전에 고려해야 할 몇 가지 사항입니다.
경쟁 우위– 유사한 앱이 이미 있나요?있다면 이 애플리케이션을 어떻게 차별화할 것인가요?
엔터프라이즈에 배포할 앱의 경우:
인프라 통합– 어떤 기존 인프라와 통합 또는 확장할 계획인가요?
또한 모바일 폼 팩터와 관련해서 앱을 평가해야 합니다.
가치– 이 앱이 사용자에게 어떤 가치를 제공하나요?사용자는 이 가치를 어떻게 활용하나요?
폼/이동성– 이 앱이 모바일 폼 팩터에서 어떻게 작동하나요?위치 인식, 카메라 등 모바일 기술을 사용하여 어떻게 가치를 부여할 수 있나요?
앱 기능 설계를 돕기 위해 행위자 및사용 사례를 정의하는 것이 유용할 수 있습니다.행위자는 애플리케이션 내에서 역할이며 보통 사용자입니다.사용 사례는 일반적으로 작업 또는 인텐트입니다.
예를 들어, 애플리케이션을 추적하는 작업은 다음 두 행위자를 포함할 수 있습니다.사용자및Friend.사용자는 친구와 함께작업 만들기및작업 공유를 할 수 있습니다.이 경우, 행위자와 함께 작업 만들기 및 작업 공유는 두 가지 구분된 사용 사례이며, 이 사용 사례를 통해 어떤 화면을 빌드해야 하고 어떤 비즈니스 엔터티 및 논리를 개발해야 하는지 알 수 있습니다.
적절한 수의 사용 사례 및 행위자를 캡처했으면 애플리케이션 디자인을 훨씬 쉽게 시작할 수 있습니다.그러면 개발 시 무슨 앱이며 앱으로 무엇을 해야 하는지보다는, 앱을 만드는 방법에 집중할 수 있습니다.
모바일 애플리케이션 디자인
앱의 특징 및 기능이 결정되면 다음 단계는 UX(사용자 환경)를 해결하는 것입니다.
UX 디자인
UX는 일반적으로 여러디자인 도구 키트중 하나를 사용하여 와이어프레임 또는 모형을 통해 수행됩니다.UX 모형을 통해 실제 UI 디자인을 고민할 필요없이 UX를 디자인할 수 있습니다.
UX 모형을 만들 때 앱의 대상이 될 다양한 플랫폼에 대한 인터페이스 지침을 고려하는 것이 중요합니다.앱은 각 플랫폼에서 “익숙한 방식”이어야 합니다.각 플랫폼의 공식 디자인 지침은 다음과 같습니다.
예를 들어, 각 앱에는 애플리케이션의 섹션 간 전환을 위한 메타포가 있습니다.iOS는 화면 하단에 탭 표시줄을 사용하고 Android는 화면 상단에 탭 표시줄을 사용하며 UWP는Pivot 또는 탭뷰를 사용합니다.
또한 하드웨어 자체는 UX 의사 결정도 지정합니다.예를 들어 iOS 디바이스에는 물리적뒤로단추가 없으므로 탐색 컨트롤러 메타포를 도입합니다.
또한 폼 팩터도 UX 결정에 영향을 줍니다.태블릿은 훨씬 더 많은 화면 공간을 보유하고 있으므로 더 많은 정보를 표시할 수 있습니다.보통 휴대폰의 여러 화면에 필요한 내용은 태블릿용으로 하나로 압축됩니다.
그리고 수많은 폼 팩터가 있기 때문에 대상으로 지정할 수 있는 중간 크기의 폼 팩터(휴대폰과 태블릿 중간)가 있습니다.
UI(사용자 인터페이스) 디자인
UX가 결정되면 다음 단계는 UI 디자인을 만드는 것입니다.UX는 일반적으로 단순한 흑백 모형이지만 UI 디자인 단계에서는 색상, 그래픽 등을 도입하고 마무리합니다.좋은 UI 디자인에 시간을 투자하는 것이 중요하며 일반적으로 가장 인기 있는 앱은 디자인이 전문적입니다.
UX와 마찬가지로 각 플랫폼마다 고유한 디자인 언어가 있으므로 잘 디자인된 애플리케이션은 각 플랫폼마다 다르게 나타날 수 있습니다.
개발
일반적으로 개발 단계는 매우 일찍 시작됩니다.사실, 아이디어가 개념/착안 단계에서 어느 정도 진행되면 기능, 가정을 검증하고 작업 범위를 이해하는 데 도움이 되는 작업 프로토타입이 자주 개발됩니다.
자습서의 나머지 부분에서는 개발 단계에 주로 초점을 둡니다.
안정화
안정화는 앱에서 버그를 찾는 프로세스입니다.예를 들어, “이 단추를 클릭하면 충돌이 발생합니다”와 같은 기능적 관점뿐만 아니라 유용성 및 성능 관점에서도 해당됩니다.개발 프로세스 내에서 매우 일찍 안정화를 시작하여 비용이 많이 들기 전에 궤도 수정이 발생하도록 하는 것이 가장 좋습니다.일반적으로 애플리케이션은프로토타입,알파,베타및릴리스 후보단계를 거칩니다.사람들마다 다르게 정의하지만 일반적으로 다음과 같은 패턴을 따릅니다.
프로토타입- 앱은 개념 증명 단계에 있으며 애플리케이션의 핵심 기능이나 특정 부분만 작동합니다.주요 버그가 있습니다.
알파– 일반적으로 핵심 기능에 대한 코드가 완성되어 있습니다(빌드되었지만 완전히 테스트되지는 않음).여전히 주요 버그가 있으며 외부 기능은 아직 없을 수 있습니다.
베타– 이제 대부분의 기능이 완료되었으며 최소한 가벼운 테스트와 버그 수정을 완료했습니다.주요 알려진 문제가 여전히 존재할 수 있습니다.
릴리스 후보– 모든 기능을 완료하고 테스트했습니다.새로운 버그가 없다면 이 앱은 시장에 릴리스할 후보입니다.
애플리케이션 테스트를 시작하는 것이 결코 이르지 않습니다.예를 들어, 프로토타입 단계에서 주요 문제가 발견되면 이를 적용하도록 앱의 UX를 계속 수정할 수 있습니다.알파 단계에서 성능 문제가 발견되면 잘못된 가정 하에 많은 코드를 작성하기 전에 아키텍처를 수정하는 것이 좋습니다.
일반적으로 애플리케이션이 수명 주기에 따라 더 이동함에 따라 더 많은 사람이 애플리케이션을 시험해 보고 테스트하며 피드백을 제공할 수 있도록 합니다. 예를 들어, 프로토타입 애플리케이션은 주요 이해 관계자에게만 표시되거나 제공될 수 있지만 릴리스 후보 애플리케이션은 미리 액세스를 등록하는 고객에게 배포될 수 있습니다.
비교적 적은 수의 디바이스에 대한 초기 테스트 및 배포를 위해 일반적으로 개발 컴퓨터에서 곧바로 배포하는 것으로 충분합니다.그러나 대상 사용자가 확대됨에 따라 이 작업은 곧 번거로울 수 있습니다.따라서 테스트 풀에 사람을 초대하고 웹을 통해 빌드를 릴리스하며 사용자 피드백을 허용하는 도구를 제공함으로써 이 프로세스를 훨씬 쉽게 만들어주는 수많은 테스트 배포 옵션을 제공합니다.
테스트 및 배포를 위해App Center를 사용하여 앱을 지속적으로 빌드, 테스트, 릴리스 및 모니터링할 수 있습니다.
배포
애플리케이션이 안정화되었으면 이제 시장에 내놓을 시간입니다.플랫폼에 따라 다양한 배포 옵션이 제공됩니다.
iOS
Xamarin.iOS 및 Objective-C 앱은 정확히 동일한 방법으로 배포됩니다.
Apple App Store– Apple의 App Store는 iTunes를 통해 Mac OS X에 기본 제공되는 전 세계적으로 사용 가능한 온라인 애플리케이션 리포지토리입니다.현재 애플리케이션을 위한 가장 널리 사용되는 배포 방법이며, 개발자는 힘들이지 않고도 온라인으로 앱을 마케팅하고 배포할 수 있습니다.
사내 배포– 사내 배포는 App Store를 통해 공개적으로 제공되지 않는 기업 애플리케이션의 내부 배포를 위한 것입니다.
애드혹 배포– 애드혹 배포는 주로 개발 및 테스트용으로 사용되며 제한된 수의 올바르게 프로비전된 디바이스에 배포할 수 있도록 해줍니다.Mac용 Xcode 또는 Visual Studio를 통해 디바이스에 배포하는 경우 이를 애드혹 배포라고 합니다.
Android
모든 Android 애플리케이션은 서명된 후 배포되어야 합니다.개발자는 개인 키로 보호되는 사용자 고유의 인증서를 사용하여 애플리케이션을 서명합니다.이 인증서는 개발자가 빌드 및 릴리스한 애플리케이션과 애플리케이션 개발자를 연결하는 신뢰성 체인을 제공할 수 있습니다.공인된 인증 기관에서 Android용 개발 인증서를 서명할 수는 있지만 대부분의 개발자는 이러한 서비스를 활용하지 않고 자신의 인증서를 자체 서명합니다.인증서의 주요 목적은 서로 다른 개발자와 애플리케이션을 구별하는 것입니다.Android는 이 정보를 사용하여 Android OS 내에서 실행되는 애플리케이션과 구성 요소 간에 권한 위임을 적용하도록 지원합니다.
다른 널리 사용되는 모바일 플랫폼과 달리, Android는 앱 배포에 대해 매우 개방적인 방식을 취합니다.디바이스는 하나의 승인된 앱 스토어로 국한되지 않습니다.대신, 누구나 무료로 앱 스토어를 만들 수 있으며 대부분의 Android 휴대폰은 타사 스토어에서 앱을 설치할 수 있습니다.
이를 통해 개발자는 잠재적으로 더 크고 더 복잡한 애플리케이션 배포 채널을 사용할 수 있습니다.Google Play는 Google의 공식 앱 스토어이지만 기타 여러 가지가 있습니다.널리 사용되는 것은 다음과 같습니다.
UWP 애플리케이션은 Microsoft Store를 통해 사용자에게 배포됩니다.개발자가 앱을 제출하여 승인을 받으면 해당 앱이 스토어에 표시됩니다.Windows 앱 게시에 대한 자세한 내용은 UWP의게시설명서를 참조하세요.
모바일 개발 고려 사항
모바일 애플리케이션을 개발하는 것이 프로세스 또는 아키텍처와 관련하여 기존의 웹/데스크톱 개발과 근본적으로 다른 것은 아니지만 몇 가지 고려해야 할 사항이 있습니다.
일반적인 고려 사항
멀티태스킹
모바일 디바이스에서 멀티태스킹(여러 응용 프로그램을 한 번에 실행)에는 두 가지 중요한 문제가 있습니다.첫째, 제한된 화면 공간에서는 여러 애플리케이션을 동시에 표시하기 어렵습니다.따라서 모바일 디바이스에서는 한 번에 하나의 앱만 포그라운드에 있을 수 있습니다.둘째, 여러 애플리케이션을 열어두고 작업을 수행하면 배터리 전원이 빨리 소모될 수 있습니다.
플랫폼마다 멀티태스킹을 다르게 처리하며, 이 내용은 잠시 후에 살펴볼 것입니다.
폼 팩터
모바일 디바이스는 일반적으로 휴대폰과 태블릿이라는 두 범주로 나뉘며 그 사이에 몇 가지 크로스오버 디바이스가 있습니다.이러한 폼 팩터 개발은 일반적으로 매우 유사하지만 애플리케이션을 설계하는 것은 매우 다를 수 있습니다.휴대폰은 화면 공간이 매우 제한되어 있는 반면 태블릿은 이보다 크기는 하지만 대부분의 랩톱보다는 여전히 화면 공간이 적은 모바일 디바이스입니다.이 때문에 모바일 플랫폼 UI 컨트롤은 소형 폼 팩터에서 효과적으로 작동하도록 특별히 설계되었습니다.
디바이스 및 운영 체제 조각화
전체 소프트웨어 개발 수명 주기에서 다양한 디바이스를 고려하는 것이 중요합니다.
개념화 및 계획– 하드웨어와 기능은 디바이스마다 다를 수 있으므로 특정 기능을 사용하는 응용 프로그램은 특정 디바이스에서 제대로 작동하지 않을 수 있습니다.예를 들어, 모든 디바이스에 카메라가 있는 것은 아니므로 화상 채팅 응용 프로그램을 제작하는 경우 일부 디바이스는 동영상을 재생할 수는 있지만 촬영할 수는 없습니다.
디자인– 응용 프로그램의 UX(사용자 경험)를 디자인할 때는 여러 디바이스의 다양한 화면 비율과 크기에 주의를 기울여야 합니다.또한 애플리케이션의 UI(사용자 인터페이스)를 디자인할 때 서로 다른 화면 해상도를 고려해야 합니다.
개발– 코드의 기능을 사용할 때 먼저 해당 기능의 존재 여부를 항상 테스트해야 합니다.예를 들어, 카메라와 같은 디바이스 기능을 사용하기 전에 항상 OS에서 해당 기능의 존재 여부를 먼저 쿼리합니다.그런 다음, 기능/디바이스를 초기화할 때 OS에서 해당 디바이스에 대한 현재 지원을 요청한 다음, 해당 구성 설정을 사용해야 합니다.
테스트– 실제 디바이스에서 조기에 자주 응용 프로그램을 테스트하는 것이 매우 중요합니다.동일한 하드웨어 사양을 포함하는 디바이스조차도 동작이 매우 다양할 수 있습니다.
제한된 리소스
모바일 디바이스는 갈수록 점점 더 강력해지고 있지만 데스크톱이나 노트북 컴퓨터에 비해 기능이 제한적인 모바일 디바이스입니다.예를 들어, 데스크톱 개발자는 일반적으로 메모리 용량에 대해 걱정하지 않습니다. 이들은 보통 실제 메모리와 가상 메모리 모두를 충분히 사용합니다. 그러나 모바일 디바이스에서는 고화질 사진 몇 장만 로드해도 순식간에 사용 가능한 모든 메모리를 소비할 수 있습니다.
또한 게임이나 텍스트 인식과 같은 프로세서를 많이 사용하는 응용 프로그램은 실제로 모바일 CPU에 부담을 주고 디바이스 성능에 부정적인 영향을 미칠 수 있습니다.
이와 같은 고려 사항 때문에 응답성을 검증하기 위해 현명하게 코드를 작성하고 실제 디바이스에 조기에 자주 배포하는 것이 중요합니다.
iOS 고려 사항
멀티태스킹
멀티태스킹은 iOS에서 매우 엄격하게 제어되며 다른 애플리케이션이 포그라운드로 오면 애플리케이션이 따라야 하는 규칙과 동작이 많습니다. 그렇지 않으면 애플리케이션이 iOS에 의해 종료됩니다.
디바이스별 리소스
특정 폼 팩터 내에서 하드웨어는 여러 모델 간에 크게 다를 수 있습니다.예를 들어, 일부 디바이스에는 후면 카메라가 있고 일부는 전면 카메라가 있으며 어떤 디바이스는 아무 것도 없습니다.
일부 이전 디바이스(iPhone 3G 이하)는 멀티태스킹도 허용하지 않습니다.
이러한 디바이스 모델 간 차이점으로 인해 기능을 사용하기 전에 해당 기능이 존재하는지 확인하는 것이 중요합니다.
OS 관련 제약 조건
애플리케이션이 잘 응답하고 안전한지 확인하기 위해 iOS는 애플리케이션이 준수해야 하는 여러 가지 규칙을 시행합니다.멀티태스킹과 관련된 규칙 외에도, 앱이 특정 시간 내에 반환해야 하는 여러 가지 이벤트 메서드가 있습니다. 특정 시간 내에 반환하지 않으면 iOS에서 종료됩니다.
또한 주목할 만한 것은 앱이 액세스할 수 있는 것을 제한하는 보안 제약 조건을 적용하는 샌드박스라는 환경에서 실행된다는 것입니다.예를 들어, 앱은 자체 디렉터리에서 읽고 쓸 수 있지만 다른 앱 디렉터리에 쓰기를 시도하면 종료됩니다.
Android 고려 사항
멀티태스킹
Android의 멀티태스팅에는 두 구성 요소가 있습니다. 첫 번째는 작업 수명 주기입니다.Android 애플리케이션의 각 화면은 작업으로 표시되며, 애플리케이션이 백그라운드에 배치되거나 포그라운드로 들어올 때 발생하는 특정 이벤트 집합이 있습니다.응답성이 좋고 올바르게 동작하는 애플리케이션을 만들려면 애플리케이션이 이 수명 주기를 준수해야 합니다.자세한 내용은작업 수명 주기가이드를 참조하세요.
Android에서 멀티태스킹에 대한 두 번째 구성 요소는 서비스 사용입니다.서비스는 애플리케이션과 독립적으로 존재하며 애플리케이션이 백그라운드에서 실행되는 동안 프로세스를 실행하는 데 사용되는 장기 실행 프로세스입니다.자세한 내용은서비스 만들기가이드를 참조하세요.
많은 디바이스 및 많은 폼 팩터
Google은 Android OS를 실행할 수 있는 디바이스에 제한을 두지 않습니다.이 개방적 패러다임은 매우 다른 하드웨어, 화면 해상도 및 비율, 디바이스 기능 및 성능을 갖춘 수많은 다양한 디바이스로 채워지는 제품 환경을 만들어냅니다.
Android 디바이스의 극단적인 조각화로 인해 대부분의 사람들은 가장 인기 있는 5개 또는 6개의 디바이스를 선택하여 디자인, 테스트 및 우선 순위를 지정합니다.
보안 고려 사항
Android OS의 애플리케이션은 모두 제한된 권한을 사용하여 별개의 격리된 ID로 실행됩니다.기본적으로 애플리케이션은 할 수 있는 것이 거의 없습니다.예를 들어, 특별한 권한이 없다면 애플리케이션은 문자 메시지를 보내거나 휴대폰 상태를 확인하거나 인터넷에 액세스할 수 없습니다!이러한 기능에 액세스하려면, 애플리케이션은 애플리케이션 매니페스트 파일에 원하는 사용 권한과 설치 시기를 지정해야 합니다. OS는 이러한 권한을 읽고 애플리케이션이 해당 권한을 요청하고 있음을 사용자에게 알린 다음, 사용자가 설치를 계속하거나 취소할 수 있도록 합니다.애플리케이션이 iOS와 같은 방식으로 큐레이트되지 않기 때문에 개방형 애플리케이션 스토어 모델로 인해 Android 배포 모델에서 필수적인 단계입니다.애플리케이션 권한 목록은 Android 설명서의매니페스트 권한참조 문서를 참조하세요.
Windows 고려 사항
멀티태스킹
UWP의 멀티태스킹은 페이지 및 애플리케이션에 대한 수명 주기와 백그라운드 프로세스라는 두 부분으로 구성됩니다.애플리케이션의 각 화면은 활성 또는 비활성(비활성 상태를 처리하거나 “삭제 표시”하는 특수 규칙이 있음)과 관련된 이벤트가 있는 Page 클래스의 인스턴스입니다.
두 번째 부분은 애플리케이션이 포그라운드에서 실행되지 않는 경우에도 작업 처리를 위한 백그라운드 에이전트를 제공합니다.
디바이스 성능
UWP 하드웨어는 유형이 거의 같지만 여전히 선택적인 구성 요소이므로 코딩하는 동안 특별한 고려 사항이 요구됩니다.옵션 하드웨어 기능으로는 카메라, 나침반 및 자이로스코프가 있습니다.특별 고려 사항이 필요한 특수한 종류의 저용량 메모리(256MB)가 있거나 개발자가 메모리 부족 지원을 제외할 수 있습니다.
use schemaTestDB; create schema schema_A; create schema schema_B; create table schema_A.TBL_A(no int); create table schema_B.TBL_B(id int); create table schema_A.TBL_AA(code int); SELECT * from schema_A.TBL_A; Create table department(deptNo int not null, deptName nvarchar(20), location nchar(20)) select * into departmentNew from department Where 1=0;--무조건 거짓,테이블 구조만 복사 create sequence dept_seq start with 10 increment by 10;--시퀀스를 넣어서 번호 자동 생성 insert departmentNew values(next value for dept_Seq,'경기부','서울'); insert departmentNew values(next value for dept_Seq,'인사부','인천'); insert departmentNew values(next value for dept_Seq,'전산부','수원'); insert departmentNew values(next value for dept_Seq,'영업부','대전'); select * from departmentNew; --시퀀스현재값 select current_value from sys.sequences where name='dept_seq'; --시퀀스의 시작값을 다시 수정하기 위한 구문 alter sequence dept_seq restart with 15; insert departmentNew values(next value for dept_Seq,'생산부','안산'); insert departmentNew values(next value for dept_Seq,'회계부','광주'); select * from departmentNew; alter sequence dept_seq restart with 35 increment by 5; insert departmentNew values(next value for dept_Seq,'회계부1','광주'); insert departmentNew values(next value for dept_Seq,'회계부2','광주'); select * from departmentNew; --시퀀스의 반복 create sequence dept_seq1 start with 100 increment by 100 minvalue 100 maxvalue 500 cycle; --반복설정 insert departmentNew values(next value for dept_Seq1,'생산부1','서울'); insert departmentNew values(next value for dept_Seq1,'인사부1','인천'); insert departmentNew values(next value for dept_Seq1,'전산부1','수원'); insert departmentNew values(next value for dept_Seq1,'영업부1','대전'); insert departmentNew values(next value for dept_Seq1,'영업부2','대전'); insert departmentNew values(next value for dept_Seq1,'영업부3','대전'); select * from departmentNew; --테이블 생성시에 시퀀스 활용법 create sequence auto_seq start with 1 increment by 1;
create table seqTest(no int default(next value for auto_seq), name nchar(30));
Declare @aaa int; declare @bbb smallint, @ccc decimal(4,2); declare @ddd nchar(20); set @aaa=10; set @bbb =5; set @ccc=10.33; set @ddd = '이름:'; select @aaa; select @bbb + @ccc; select @aaa,* from departmentNew; select top(@bbb) deptName,* from departmentNew;
--if 문
declare @var1 int; set @var1 = 10; if @var1 = 10 begin print '@var1이 10이다' end else begin print '@var1이 10이아니다' end;
--변수 초기화 declare @var2 int =100; select @var2;
declare @score int =78,@res nchar(1) if @score >= 90 set @res = 'A' else if @score >= 80 set @res='B' else if @score >= 70 set @res='C' else if @score >= 60 set @res='D' else set @res='F' print '점수:' + cast(@score as nchar(30)); print N'학점:' + @res; --한글이기때문에 N을 넣어야함.
--case declare @score int = 100,@res nchar(1); set @res = case when(@score >= 90) then 'A' when(@score >= 80) then 'B' when(@score >= 70) then 'C' when(@score >= 60) then 'D' else 'F' end print '점수:' + cast(@score as nchar(30)); print N'학점:' + @res; --한글이기때문에 N을 넣어야함.
select name,price,case when (amount >=80) then '최고인기상품' when (amount >=50) then '인기상품' when (amount >= 30) then '추천상품' else '보통상품' end as '상품등급' from products;
--반복문 : while / break / continue / return /* while 조건 begin SQL명령문 end */ declare @i int = 0 ,@sum int =0 while(@i<=100) begin set @sum += @i set @i += 1 end
select @sum;
declare @i int = 1,@sum int =0;
while(@i <=100) begin if(@i % 3 =0) begin print '3의배수:' + cast(@i as char(3)) set @i += 1 continue --while end문으로 이동 end set @sum += @i --3의배수시 실행않됨 if(@sum>2000) break --3의배수시 실행않됨,while문을 빠져나옴 set @i += 1 --3의배수시 실행않됨 end;
print '합계:' + cast(@sum as char(10))
--goto : 제한적으로사용,지정한위치로 이동
declare @i int = 1,@sum int =0;
while(@i <=100) begin if(@i % 3 =0) begin print '3의배수:' + cast(@i as char(3)) set @i += 1 continue --while end문으로 이동 end set @sum += @i --3의배수시 실행않됨 if(@sum>2000) goto aa --3의배수시 실행않 set @i += 1 --3의배수시 실행않됨 end
aa:
print '합계:' + cast(@sum as char(10))
--waitfor 실행을 잠시 멈추고 기다림 --waitfor time,waitfor delay
begin waitfor delay '00:00:03' print '3초간 일시정지후 실행합니다..' end begin waitfor time '12:30' print '정해진시간에 실행합니다...' end --예외 처리(try catch문) /* begin try sql 명령 end try begin catch 오류시실행될 명령 end catch */ begin try insert departmentNew values('테스트','',''); print '정상처리되었습니다..' end try
begin catch print '오류발생' print '오류번호:' print error_number() print '오류메세지' print error_message() print '오류라인' print error_line() end catch --오류발생시 사용할 함수 제공 /* .error_number():오류번호 .error_message():오류메세지 .error_serverity():오류심각성 .error_state():오류 상태 .error_line():오류라인 .error_procesude():오류발생 프로시저나 트리거 이름을 알려줌. */
--오류를 강제로 발생시키는 함수 --raiserror,throw --오류의 심각도(0~18까지,기본값은 16) --raiserror(메세지,심각도,상태) --throw(메세지,상태)
--execute(exec),스파이스열,임시테이블 --exec, execute:SQL문을 실행시키는 명령어 declare @sql varchar(100); set @sql = 'select * from departmentnew where deptno = 10' exec(@sql);
--테이블의 명칭 : tbl_04_12,tbl_04_13,동적으로 테이블을 만들어서 사용가능
declare @todayDate Date declare @Month varchar(2) declare @day varchar(2) declare @sql varchar(100) set @todayDate = getDate() set @Month = month(@todayDate) set @day = day(@todayDate); set @sql = 'create table test_' + @Month + '_' + @day set @sql += '(no int,name char(10))' exec(@sql);
--스파스열 : null값이 많이 들어가는 열의 저장공간을 낭비하지 않게 하기위해서 지정하는 열 --키워드 : sparse 5만건 기준으로 약 1/5수준으로 저장공간을 사용
create table aaa( no int identity, name char(100) null ); go create table sparseTbl( no int identity, name char(100) sparse null );
declare @i int =0 while @i<10000 begin insert aaa values(null); insert aaa values(null); insert aaa values(null); insert aaa values(null); insert aaa values(REPLICATE('s',100)); --sparse테이블 insert sparseTbl values(null); insert sparseTbl values(null); insert sparseTbl values(null); insert sparseTbl values(null); insert sparseTbl values(REPLICATE('s',100)); set @i += 1; end
--임시테이블 --#테이블명 하나 사용 : 생성한 사용자만 사용가능 --쿼리차이 닫히면 사라짐. --##테이블명 두개 사용 : 모든 사용자가 사용가능 --쿼리창이 닫히고 사용자가 없으면 사라짐.
create table #tempTbl1 ( no int,name nchar(10) ); create table ##tempTbl2( no int,name nchar(10) );
select * from #tempTbl1 select * from ##tempTbl2 --뷰테이블 select * into copy_departmentnew from departmentnew --테이블 복사 select * from copy_departmentnew select deptNo,DeptName,location from departmentNew create view depart_View as select deptNo,DeptName,location from departmentNew where location ='서울' select * from depart_View exec sp_helptext depart_View; --뷰에 정의된 내용을 보수 있음. Insert depart_View values(1100,'회계부','서울') --뷰를 통해서도 저장이됨.
--복잡한 쿼리문을 단순화해서 사용하기 위해서도 뷰를 사용 select deptNo,DeptName,location from departmentNew create table emp(no int default(next value for auto_seq), name nchar(30),deptNo int); insert emp(name,deptNo) values('김동길1','10'); insert emp(name,deptNo) values('김동길2','20'); insert emp(name,deptNo) values('김동길3','30'); insert emp(name,deptNo) values('김동길4','40'); insert emp(name,deptNo) values('김동길5','50'); insert emp(name,deptNo) values('김동길6','60'); insert emp(name,deptNo) values('김동길7','70'); insert emp(name,deptNo) values('김동길8','80'); insert emp(name,deptNo) values('김동길11','100'); insert emp(name,deptNo) values('김동길12','15'); insert emp(name,deptNo) values('김동길13','25'); insert emp(name,deptNo) values('김동길14','35'); insert emp(name,deptNo) values('김동길15','40'); insert emp(name,deptNo) values('김동길16','100'); insert emp(name,deptNo) values('김동길17','300'); insert emp(name,deptNo) values('김동길18','400');
select e.no,e.name,d.deptNo,d.deptName,d.location from emp e, departmentNew d where e.deptNo = d.deptNo
create view emp_dept_view as select e.no,e.name,d.deptNo,d.deptName,d.location from emp e, departmentNew d where e.deptNo = d.deptNo and d.deptName = '영업부'
select * from emp_dept_view exec sp_helptext emp_dept_view; --뷰에 정의된 내용을 보수 있음. exec sp_help emp_dept_view;--뷰에 구조를 보여줌 create view emp_enc with encryption as select e.no,e.name,d.deptNo,d.deptName,d.location from emp e, departmentNew d where e.deptNo = d.deptNo and d.deptName = '영업부' exec sp_helptext emp_enc; --암호화 되어있어 뷰를 볼 수 없음. exec sp_help emp_enc; --암호화되어있어도 구조는 확인가능 drop view emp_dept_view--뷰삭제 select * from sys.sql_modules --정의된 모든 뷰를 볼수 있음,테이블이름이 않나옴.. select object_name(object_id) as emp_dept_view,definition,* from sys.sql_modules --테이블명까지 나오나 암호화되어있은 뷰는 못 봄.
--뷰를 수정 alter view emp_dept_view as select * from emp Where deptNo=40 with check Option; --40번에 해당하는 건만 수정,저장 가능.
--인덱스 : 데이터의 변경 작업이 자주 일어날 경우에는 성능이 나빠질 수 있다. --Page,extent /* 페이지 : 데이터를 저장하는 기본단위(8kb) 헤더,Data rows,Row Offset으로 구성
헤더:이전페이지와 가음페이지의 정보가 포함. Data rows:실제 데이터가 저장되는 영역 Row Offset: 각행의 첫 번째 바이트가 페이지의 시작에서 얼마나 떨어져 있는지에 대한 정보를 포함하고 있다.
페이지 종류 .데이터 페이지 : 데이터를 저장하기 위한 페이지 .인덱스 페이지 : 인데스를 저장하는 페이지
익스텐트(extent) :테이블이나 인덱스가 저장되는 기본단위, 8개의 페이지가 모여서 하나의 익스텐트를 이룬다.
단일 익스텐트 : 하나의 개체만 할당된 익스텐트 혼합 익스텐트 : 하나 이상의 개체의 페이지가 들어 있는 익스텐트
--인덱스의 구조 :인덱스는 기본적으로 정렬 되어있다. 인덱스는 B-tree구조로 구성되어 있다. */ --인덱스 유형
--clustered 인덱스(물리적으로 데이터를 정렬 시킴) /* :원하는 컬럼에 클러스터드 인덱스를 만들게 되면 기본적으로 데이터를 정렬을 시킨다.(오름차순으로 정렬) .한테이블에 하나의 클러스터드 인덱스만 만들수있다. .기본키를 만들게 되면 기본키에 클러스터드 인덱스가 만들어진다. (기본키에는 넌클러스터드 인덱스를 만들 수 도 있다.) .수정삭제 발생시 논클러스터드 보다 느리다.(데이터 재정렬 때문) */
--non clustered 인데스(논리적으로 데이터를 정렬 시킴) /* :원하는 컬럼에 넌클러스터드 인덱스를 만들게 되면, 데이터 페이지의 위치정보를 인덱스로 구성하게된다. .한테이블에 만들 수 있는 넌 클러스터드 인덱스는 여러개가 가능 .기본적으로 클러스터드 인덱스 보다 검색 속도가 느리다. */ create table tbl01(aa int primary key, bb int, cc int); --인덱스 정보확인 프로시져 exec sp_helpIndex tbl01
create table tbl02(aa int primary key, bb int unique, cc int unique,dd int); exec sp_helpIndex tbl02 --aa는 클러스터드 인덱스,bb,cc는 넌 클러스터드 인덱스가 자동으로 생성
--기본키에도 넌 클러스터드 인덱스 설정 가능 create table tbl03(aa int primary key nonclustered,bb int unique,cc int unique,dd int); exec sp_helpindex tbl03;
create table tbl04(aa int primary key nonclustered,bb int unique clustered,cc int unique,dd int) exec sp_helpindex tbl04;
create table clusteredTbl( id char(8) not null, name NVARCHAR(10) not null);
alter table ccc add constraint UK_mix_name unique(name) exec sp_helpindex ccc
select address from ccc where name = '김말똥'
--알아두어야할 용어 /* Table scan : 데이터페이지를 처음부터 끝까지 검색하는 방식 인덱스가 없을 경우에 주로 사용하는 방식 Index seek : 넌클러스터드 인덱스에서 데이터를 찾는 방식
RID lookup : 넌클러스터드 인덱스에서 키를 검색 한 후, 실제 데이터 페이지를 찾는 다라는 의미
Clustered Index seek : 클러스터드 인덱스에서 데이터를 찾는 방식
Key lookup : 넌 클러스터드 인덱스에서 키를 검색한 후 클러스터드 인덱스에서 데이터를 찾는 방식
Clustered Index Scan : table scan방식과 비슷한 개념으로 전체를 찾아본다는 의미
*/
select * from ccc where id = 'aa' select * from ccc
--인덱스를 직접 생성하는 방법 /* create [unique][clustered | nonclustered] index 인덱스명 on 테이블명(column [asc | desc])
PAD_INDEX : 기본값은 OFF,ON으로 설정되면 FILLFACTOR에 페이지 여유분을 설정할 수 있다. FILLFACTOR : 페이지의 여유분을 설정한다.
예>with fillfactor 80 ->페이지에 20%의 여유분을 두겠다는 의미
.sort_in_tempDB : 기본값은 OFF,ON설정하면 디스크의 분리효과가 생긴다. .online : 기본값은 OFF,ON 설정시 인덱스 생성중에서 기본 테이블에 쿼리가 가능하도록 하는 옵션
*/ --인덱스를 변경하는 방법 /* alter index [인덱스 명 | all] on 테이블명 rebuild 옵션:인덱스를 삭제하고 다시 생성하는 옵션 예> alter index all on ccc rebuild with (online = on)
reorganize : 인덱스를 다시 구성하는 옵션(삭제하지 않고, 즉 조각모음) */
--인덱스 삭제 /* delete index 테이블명.인덱스명 .primary key, unique 제약조건으로 자동생성된 인덱스는 drop index로 제거 할 수 없다. 이경우에는 alter table 구문으로 제약조건을 삭제하면 인덱스가 삭제된다. .시스템 테이블의 인덱스는 drop index구문으로 삭제 할 수없다. .혼합형 테이블에서 인덱스를 제거할 경우에는 넌클러스터드 인덱스를 제거하는 것이 좋다. */ select * from ccc
exec sp_helpindex ccc;
alter table ccc drop UK_mix_name;--인덱스 삭제
create index idx_name on ccc(name) exec sp_helpindex ccc;
create unique index idx_name on ccc(name); --네임에 유니크를 추가
--트랜잭션 : 하나의 논리적인 작업단위로 여러명령의 묶음. --여러명령의 묶음 : insert/update/delete 명령들의 묶음이라도 봐도 된다.
--예 begin transaction --자동으로 sql server에서 붙인다. update ccc set address='경기도 시흥' where id = 'aaa'; commit transaction --자동으로 sql server에서 붙인다.
--commit : 데이터베이스에 반영을 하겠다는 명령
--예 begin transaction --사용자가 명시 update ccc set address='경기도 시흥1' where id = 'aaa'; update ccc set address='경기도 시흥2' where id = 'bbb'; update ccc set address='경기도 시흥3' where id = 'ddd'; commit transaction --사용자가 명시 --commit : 데이터베이스에 반영을 하겠다는 명령
begin tran Update cccc set number =10 where number=100; Update cccc set number =20 where number=200; Update cccc set number =30 where number=300; commit tran
select * from cccc
--현재 실행 중인 트랜잭션의 갯수를 알아보기위한 함수 --시스템 함수 @@trancount select @@TRANCOUNT
--다른 쿼리창에서 select * from cccc 실행해도 트랜잭션이 진행중일 경우 않보임 --트랜잭션 중일 경우에는 해당 테이블에 Lock을 발생시킴. --따라서 다른 사용자가 접근 할 수 없게 된다. --ctrl + alt + del키를 누른다. --만약 LOCK을 해제하면 볼수 있는데 해제하는 방법은 --alter database sampleDB set allow_snapshot_isolation on; --set transaction isolation level snapshot; --원상태는 --alter database sampleDB set allow_snapshot_isolation off;
--구문형식 /* begin tran SQL 명령... Commit tran(=commit work)
.commit tran : 트랜잭션의 이름을 지정해서 commit을 시킬 수 있다. .commit work : 현재 실행중인 트랜잭션 중에서 가장 가까운 트랜잭션만을 커밋 시킨다. .rollback tran: 트랜잭션을 취소 트랜잭션의 내용이 길 경우 중간에 위치를 지정해서 그 지점까지의 저장 할 수 있다. .save tran 저장지점 */
--트랜잭션의 종류 /* 자동 커밋 트랜재션 : 자동적으로 begin tran 과 commit tran을 명시하는 방식 SQL Server에서는 자동 커밋을 디폴트로 사용한다. 명시적 트랜잭션 : 사용자가 직접 begin tran과 commit tran,rollback tran을 명시하는 방식. 묵시적(암시적(트랜잭션):쿼리문을 실행했을 때 자동으로 begin tran을 명시하지만, commit tran,rollback tran은 자동으로 명시하지 않는 방식(사용자가 직접 commit tran을 결정하는 방식)
설정방법 : set implict transaction on
alter table, fetch, revoke, create, grant, select, delete, insert,update,truncate table,drop,open 암시적 트랜잭션이 한번이 수행되면,commit이나 rollback명령이 수행되기 전까지는 암시적트랜잭션이 중복되어 시작되지 않는다. */
create table tran_ex2( name varchar(10), money int,
--유비가 장비에게 500원을 송금하는 예 begin update tran_ex2 set money=money-500 where name='유비'; commit tran
begin update tran_ex2 set money=money + 500 where name='장비'; commit tran --유비가 장비에게 800원을 송급처리 begin update tran_ex2 set money = money - 800 where name='유비'; update tran_ex2 set money = money + 800 where name='장비'; commit tran
--check 조건:money >=0 ->논리적인 오류 rollback이 실행되지 않는다. --이러한 논리적인 오류가 발생했을 경우에는 --예외 처리를 한다. begin try ~end try begin catch ~ end catch를 이용한다. begin try begin tran update tran_ex2 set money = money - 500 where name='유비'; update tran_ex2 set money = money + 500 where name='장비'; commit tran print '송금처리가 되었습니다.' end try begin catch rollback tran print '잔액이 부족합니다.' end catch -------이상 5강------------ --단순한 레코드 증가용 테이블 create table tran_ex3( no int identity ); --트랜잭션의 갯수를 저장하는 테이블 create table tran_ex4( no int, tranCnt int );
--트리거 만들기 CREATE TRIGGER trancnt on tran_ex3 for insert as declare @no int; select @no = no from inserted; insert tran_ex4 values(@no,@@TranCount);
insert tran_ex3 default values;
SELECT * from tran_ex3 SELECT * from tran_ex4
begin tran begin tran print '트랜잭션의수:' + cast(@@tranCount as char(3)); commit tran print '트랜잭션의 수:' + cast(@@trancount as nchar(3)); commit tran
print '트랜잭션의 수:' + cast(@@trancount as nchar(3));
CREATE TABLE TRAN_ROLLback_EX1( NO INT ); INSERT TRAN_ROLLBACK_EX1 VALUES(10);
BEGIN TRAN --모든 TRAN 롤백 UPDATE TRAN_ROLLBACK_EX1 SET NO = 100; BEGIN TRAN UPDATE TRAN_ROLLBACK_EX1 SET NO =200; SELECT * FROM TRAN_ROLLBACK_EX1; ROLLBACK TRAN SELECT * FROM TRAN_ROLLBACK_EX1; ROLLBACK TRAN SELECT * FROM TRAN_ROLLbACK_EX1;
--SAVA TRAN 문응용 : TRAN별로 롤백 BEGIN TRAN UPDATE TRAN_ROLLback_EX1 SET NO =100; SAVE TRAN [POS1] BEGIN TRAN UPDATE TRAN_ROLLBACK_EX1 SET NO = 200; SELECT * FROM TRAN_ROLLback_EX1; ROLLBACK TRAN[POS1] SELECT * FROM TRAN_ROLLback_EX1; ROLLBACK TRAN SELECT * FROM TRAN_ROLLback_EX1 --이상6강
SET IMPLICIT_transactions on;
CREATE table Tran_tbl( --암시적트랜잭션이 시작되는 지점 no int ); go
Building mobile apps can be as easy as opening up the IDE, writing and testing an app, and submitting to an App Store – all done in an afternoon.Or it can be an extremely involved process that involves rigorous up-front design, usability testing, QA testing on thousands of devices, a full beta lifecycle, and then deployment a number of different ways.
When considering how to build Android and iOS applications, many people think that the native languages, Objective-C, Swift, Java, and Kotlin, are the only choice.
Xamarin allows you develop in C#, with a class library and runtime that works across all many platforms, including iOS, Android, and Windows, while still compiling native (non-interpreted) applications that are performant enough even for demanding games.
Xamarin combines all of the abilities of the native platforms and adds a number of powerful features of its own, including:
Complete Binding for the underlying SDKs– Xamarin contains bindings for nearly the entire underlying platform SDKs in both iOS and Android.Additionally, these bindings are strongly-typed, which means that they’re easy to navigate and use, and provide robust compile-time type checking and during development.This leads to fewer runtime errors and higher-quality apps.
Objective-C, Java, C, and C++ Interop– Xamarin provides facilities for directly invoking Objective-C, Java, C, and C++ libraries, giving you the power to use a wide array of 3rd party code that has already been created.This lets you take advantage of existing iOS and Android libraries written in Objective-C, Java, or C/C++.Additionally, Xamarin offers binding projects that allow you to easily bind native Objective-C and Java libraries using a declarative syntax.
Modern Language Constructs– Xamarin applications are written in C#, a modern language that includes significant improvements over Objective-C and Java such as *Dynamic Language Features,Functional Constructssuch as *Lambdas, *LINQ,Parallel Programmingfeatures, sophisticated *Generics, and more.
Amazing Base Class Library (BCL)– Xamarin applications use the .NET BCL, a large collection of classes that have comprehensive and streamlined features such as powerful XML, Database, Serialization, IO, String, and Networking support, and more.Existing C# code can be compiled for use in an app, which provides access to thousands of libraries that allow you do things that aren’t covered in the BCL.
Modern Integrated Development Environment (IDE)– Xamarin uses Visual Studio for Mac on macOS and Visual Studio on Windows.These are both modern IDEs that include features such as code auto completion, a sophisticated Project and Solution management system, a comprehensive project template library, integrated source control, and many others.
Mobile Cross Platform Support– Xamarin offers sophisticated cross-platform support for the three major mobile platforms of iOS, Android, and Windows.Applications can be written to share up to 90% of their code, and our Xamarin.Mobile library offers a unified API to access common resources across all three platforms.This can significantly reduce both development costs and time to market for mobile developers that target the three most popular mobile platforms.
Because of Xamarin’s powerful and comprehensive feature set, it fills a void for application developers that want to use a modern language and platform to develop cross-platform mobile applications.
Xamarin offers two commercial products: Xamarin.iOS and Xamarin.Android.They’re both built on top ofMono, an open-source version of the .NET Framework based on the published .NET ECMA standards.Mono has been around almost as long as the .NET framework itself, and runs on nearly every imaginable platform including Linux, Unix, FreeBSD, and macOS.
On iOS, Xamarin’sAhead-of-Time(AOT) Compiler compiles Xamarin.iOS applications directly to native ARM assembly code.On Android, Xamarin’s compiler compiles down toIntermediate Language(IL), which is thenJust-in-Time(JIT) compiled to native assembly when the application launches.
In both cases, Xamarin applications utilize a runtime that automatically handles things such as memory allocation, garbage collection, underlying platform interop, etc.
Xamarin.iOS.dll and Mono.Android.dll
Xamarin applications are built against a subset of the .NET BCL known as the Xamarin Mobile Profile.This profile has been created specifically for mobile applications and packaged in the Xamarin.iOS.dll and Mono.Android.dll (for iOS and Android respectively).This is much like the way Silverlight (and Moonlight) applications are built against the Silverlight/Moonlight .NET Profile.In fact, the Xamarin Mobile profile is equivalent to the Silverlight 4.0 profile with a bunch of BCL classes added back in.
In addition to the BCL, these .dlls include wrappers for nearly the entire iOS SDK and Android SDK that allows the underlying SDK APIs to be invoked directly from C#.
Application output
When Xamarin applications are compiled, the result is an Application Package, either an .app file in iOS, or .apk file in Android.These files are indistinguishable from application packages built with the platform's default IDEs and are deployable in the exact same way.
Next steps
Now you've learned a little about how Xamarin works, the next step is to start building an app using one of these guides:
