
Programming Kotlin Applications
Description
Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.
Programming Kotlin Applications: Building Mobile and Server-Side Applications with Kotlin drops readers into the fast lane for learning to develop with the Kotlin programming language. Authored by accomplished cloud consultant and technology professional Brett McLaughlin, Programming Kotlin Applications provides readers with the pragmatic and practical advice they need to build their very first Kotlin applications.
Designed to give readers a thorough understanding of Kotlin that goes beyond mere mobile programming, this book will help you:
* Learn how to develop your first Kotlin project
* Understand how Kotlin securely protects and stores information
* Advocate for using Kotlin in your own professional and personal environments
* Understand Kotlin's goals and how to use it as its best
* Know when to avoid using Kotlin
Programming Kotlin Applications is written in a highly approachable and accessible way without the fluff and unrealistic samples that characterize some of its competitor guides. Perfect for developers familiar with another object-oriented programming language like Java or Ruby, or for people who want to advance their skillset in the Kotlin environment, this book is an indispensable addition to any programmer's library.
More details
Other editions
Additional editions

Person
Brett Mclaughlin has over two decades of experience working and writing in technology. He focuses on cloud and enterprise computing and has become a recognized and trusted name in helping organizations migrate to the cloud, especially with Amazon Web Services. He has led large-scale cloud migrations for NASA's Earth Science program as well as the RockCreek Group's financial platform. He is a sought-after speaker, author, and educator.
Visit us at wrox.com for free code samples.
Content
- Cover
- Title Page
- Copyright
- About the Author
- About the Technical Editor
- Acknowledgments
- Contents
- Introduction
- Chapter 1 Objects All the Way Down
- Kotlin: A New Programming Language
- What is Kotlin?
- What Does Kotlin Add to Java?
- Kotlin is Object-Oriented
- Interlude: Set Up Your Kotlin Environment
- Install Kotlin (and an IDE)
- Install IntelliJ
- Create Your Kotlin Program
- Compile and Run Your Kotlin Program
- Fix Any Errors as They Appear
- Install Kotlin (and Use the Command Line)
- Command-Line Kotlin on Windows
- Command-Line Kotlin on Mac OS X
- Command-Line Kotlin on UNIX-Based Systems
- Verify Your Command-Line Installation
- Creating Useful Objects
- Pass In Values to an Object Using Its Constructor
- Print an Object with toString()
- Terminology Update: Functions and Methods
- Print an Object (and Do It with Shorthand)
- Override the toString() Method
- All Data Is Not a Property Value
- Initialize an Object and Change a Variable
- Kotlin Auto-Generates Getters and Setters
- Terminology Update: Getters, Setters, Mutators, Accessors
- Constants Can't Change (Sort of)
- Chapter 2 It's Hard to Break Kotlin
- Upgrade Your Kotlin Class Game
- Name a File According to Its Class
- Organize Your Classes with Packages
- Put Person in a Package
- Classes: The Ultimate Type in Kotlin
- Kotlin Has a Large Number of Types
- Numbers in Kotlin
- Letters and Things
- Truth or Fiction
- Types Aren't Interchangeable (Part 1)
- You Must Initialize Your Properties
- Types Aren't Interchangeable (Part 2)
- You Can Explicitly Tell Kotlin What Type to Use
- Try to Anticipate How Types Will Be Used
- It's Easy to Break Kotlin (Sort of)
- Overriding Property Accessors and Mutators
- Custom-Set Properties Can't Be in a Primary Constructor
- Move Properties Out of Your Primary Constructors
- Initialize Properties Immediately
- Try to Avoid Overusing Names
- Override Mutators for Certain Properties
- Classes Can Have Custom Behavior
- Define a Custom Method on Your Class
- Every Property Must Be Initialized
- Assign an Uninitialized Property a Dummy Value
- Tell Kotlin You'll Initialize a Property Later
- Assign Your Property the Return Value from a Function
- Sometimes You Don't Need a Property!
- Type Safety Changes Everything
- Writing Code Is Rarely Linear
- Chapter 3 Kotlin Is Extremely Classy
- Objects, Classes, and Kotlin
- All Classes Need an equals(x) Method
- Equals(x) Is Used to Compare Two Objects
- Override equals(x) to Make It Meaningful
- Every Object Is a Particular Type
- A Brief Introduction to Null
- Every Object Instance Needs a Unique hashCode()
- All Classes Inherit from Any
- Always Override hashCode() and equals(x)
- Default Hash Codes Are Based on Memory Location
- Use Hash Codes to Come Up with Hash Codes
- Searching (and Other Things) Depend on Useful and Fast equals(x) and hashCode()
- Multiple Properties to Differentiate Them in hashCode()
- Use == over equals(x) for Speed
- A Quick Speed Check on hashCode()
- Basic Class Methods Are Really Important
- Chapter 4 Inheritance Matters
- Good Classes Are Not Always Complex Classes
- Keep It Simple, Stupid
- Keep It Flexible, Stupid
- Classes Can Define Default Values for Properties
- Constructors Can Accept Default Values
- Kotlin Expects Arguments in Order
- Specify Arguments by Name
- Change the Order of Arguments (If You Need)
- Secondary Constructors Provide Additional Construction Options
- Secondary Constructors Come Second
- Secondary Constructors Can Assign Property Values
- You Can Assign null to a Property . . . Sometimes
- null Properties Can Cause Problems
- Handle Dependent Values With Custom Mutators
- Set Dependent Values in a Custom Mutator
- All Property Assignments Use the Property's Mutator
- Nullable Values Can Be Set to null!
- Limit Access to Dependent Values
- When Possible, Calculate Dependent Values
- You Can Avoid Parentheses with a Read-Only Property
- Need Specifics? Consider A Subclass
- Any Is the Base Class for Everything in Kotlin
- { . . . } Is Shorthand for Collapsed Code
- A Class Must Be Open for Subclassing
- Terminology: Subclass, Inherit, Base Class, and More
- A Subclass Must Follow Its Superclass's Rules
- A Subclass Gets Behavior from All of Its Superclasses
- Your Subclass Should Be Different Than Your Superclass
- Subclass Constructors Often Add Arguments
- Don't Make Mutable What Isn't Mutable
- Sometimes Objects Don't Exactly Map to the Real World
- Generally, Objects Should Map to the Real World
- Chapter 5 Lists and Sets and Maps, Oh My!
- Lists Are Just a Collection of Things
- Kotlin Lists: One Type of Collection
- Collection Is a Factory for Collection Objects
- Collection Is Automatically Available to Your Code
- Mutating a Mutable List
- Getting Properties from a Mutable List
- Lists (and Collections) Can Be Typed
- Give Your Lists Types
- Iterate over Your Lists
- Kotlin Tries to Figure Out What You Mean
- Lists Are Ordered and Can Repeat
- Order Gives You Ordered Access
- Lists Can Contain Duplicate Items
- Sets: Unordered but Unique
- In Sets, Ordering Is Not Guaranteed
- When Does Order Matter?
- Sort Lists (and Sets) on the Fly
- Sets: No Duplicates, No Matter What
- Sets "Swallow Up" Duplicates
- Sets Use equals(x) to Determine Existing Membership
- Iterators Aren't (Always) Mutable
- Maps: When a Single Value Isn't Enough
- Maps Are Created by Factories
- Use Keys to Find Values
- How Do You Want Your Value?
- Filter a Collection by . . . Anything
- Filter Based on a Certain Criterion
- Filter Has a Number of Useful Variations
- Collections: For Primitive and Custom Types
- Add a Collection to Person
- Allow Collections to Be Added to Collection Properties
- Sets and MutableSets Aren't the Same
- Collection Properties Are Just Collections
- Chapter 6 The Future (in Kotlin) Is Generic
- Generics Allow Deferring of a Type
- Collections Are Generic
- Parameterized Types Are Available Throughout a Class
- Generic: What Exactly Does It Refer To?
- Generics Try to Infer a Type When Possible
- Kotlin Looks for Matching Types
- Kotlin Looks for the Narrowest Type
- Sometimes Type Inference Is Wrong
- Don't Assume You Know Object Intent
- Kotlin Doesn't Tell You the Generic Type
- Just Tell Kotlin What You Want!
- Covariance: A Study in Types and Assignment
- What about Generic Types?
- Some Languages Take Extra Work to Be Covariant
- Kotlin Actually Takes Extra Work to Be Covariant, Too
- Sometimes You Have to Make Explicit What Is Obvious
- Covariant Types Limit the Input Type as Well as the Output Type
- Covariance Is Really about Making Inheritance Work the Way You Expect
- Contravariance: Building Consumers from Generic Types
- Contravariance: Limiting What Comes Out Rather Than What Comes In
- Contravariance Works from a Base Class Down to a Subclass
- Contravariant Classes Can't Return a Generic Type
- Does Any of This Really Matter?
- Unsafevariance: Learning The Rules, then Breaking Them
- Typeprojection Lets You Deal with Base Classes
- Variance Can Affect Functions, Not Just Classes
- Type Projection Tells Kotlin to Allow Subclasses as Input for a Base Class
- Producers Can't Consume and Consumers Can't Produce
- Variance Can't Solve Every Problem
- Chapter 7 Flying through Control Structures
- Control Structures are The Bread and Butter of Programming
- If and Else: The Great Decision Point
- !! Ensures Non-Nullable Values
- Control Structures Affect the Flow of Your Code
- if and else Follow a Basic Structure
- Expressions and if Statements
- Use the Results of an if Statement Directly
- Kotlin Has No Ternary Operator
- A Block Evaluates to the Last Statement in That Block
- if Statements That Are Assigned Must Have else Blocks
- When Is Kotlin's Version of Switch
- Each Comparison or Condition Is a Code Block
- Handle Everything Else with an else Block
- Each Branch Can Support a Range
- Each Branch Usually Has a Partial Expression
- Branch Conditions Are Checked Sequentially
- Branch Conditions Are Just Expressions
- When Can Be Evaluated as a Statement, Too
- For Is for Looping
- For in Kotlin Requires an Iterator
- You Do Less, Kotlin Does More
- For Has Requirements for Iteration
- You Can Grab Indices Instead of Objects with for
- Use While to Execute until a Condition Is False
- While Is All about a Boolean Condition
- A Wrinkle in while: Multiple Operators, One Variable
- Combine Control Structures for More Interesting Solutions
- Do . . . While Always Runs Once
- Every do . . . while Loop Can Be Written as a while Loop
- If Something Must Happen, Use do . . . while
- do . . . while Can Be a Performance Consideration
- Get out of a Loop Immediately with Break
- Break Skips What's Left in a Loop
- You Can Use a Label with break
- Go to the Next Iteration Immediately with Continue
- Continue Works with Labels as Well
- If versus continue: Mostly Style over Substance
- Return Returns
- Chapter 8 Data Classes
- Classes in the Real World are Varied But Well Explored
- Many Classes Share Common Characteristics
- Common Characteristics Result in Common Usage
- A Data Class Takes the Work Out of a Class Focused on Data
- Data Classes Handle the Basics of Data for You
- The Basics of Data Includes hashCode() and equals(x)
- Destructuring Data through Declarations
- Grab the Property Values from a Class Instance
- Destructuring Declarations Aren't Particularly Clever
- Kotlin Is Using componentN() Methods to Make Declarations Work
- You Can Add componentN() Methods to Any Class
- If You Can Use a Data Class, You Should
- You Can "Copy" an Object or Make a Copy of an Object
- Using = Doesn't Actually Make a Copy
- If You Want a Real Copy, Use copy()
- Data Classes Require Several Things From You
- Data Classes Require Parameters and val or var
- Data Classes Cannot Be Abstract, Open, Sealed, or Inner
- Data Classes Add Special Behavior to Generated Code
- You Can Override Compiler-Generated Versions of Many Standard Methods
- Supertype Class Functions Take Precedence
- Data Classes Only Generate Code for Constructor Parameters
- Only Constructor Parameters Are Used in equals()
- Data Classes are Best Left Alone
- Chapter 9 Enums and Sealed, More Specialty Classes
- Strings Are Terrible as Static Type Representations
- Strings Are Terrible Type Representations
- Capitalization Creates Comparison Problems
- This Problem Occurs All the Time
- String Constants Can Help . . . Some
- Companion Objects Are Single Instance
- Constants Must Be Singular
- Companion Objects Are Singletons
- Companion Objects Are Still Objects
- You Can Use Companion Objects without Their Names
- Using a Companion Object's Name Is Optional
- Using a Companion Object's Name Is Stylistic
- Companion Object Names Are Hard
- You Can Skip the Companion Object Name Altogether
- Enums Define Constants and Provide Type Safety
- Enums Classes Provide Type-Safe Values
- Enums Classes Are Still Classes
- Enums Give You the Name and Position of Constants
- Each Constant in an enum Is an Object
- Each Constant Can Override Class-Level Behavior
- Sealed Classes Are Type-Safe Class Hierarchies
- Enums and Class Hierarchies Work for Shared Behavior
- Sealed Classes Address Fixed Options and Non-Shared Behavior
- Sealed Classes Don't Have Shared Behavior
- Sealed Classes Have a Fixed Number of Subclasses
- Subclasses of a Sealed Class Don't Always Define Behavior
- when Requires All Sealed Subclasses to Be Handled
- when Expressions Must Be Exhaustive for Sealed Classes
- else Clauses Usually Don't Work for Sealed Classes
- else Clauses Hide Unimplemented Subclass Behavior
- Chapter 10 Functions and Functions and Functions
- Revisiting the Syntax of a Function
- Functions Follow a Basic Formula
- Function Arguments Also Have a Pattern
- Default Values in Constructors Are Inherited
- Default Values in Functions Are Inherited
- Default Values in Functions Cannot Be Overridden
- Default Values Can Affect Calling Functions
- Calling Functions Using Named Arguments Is Flexible
- Function Arguments Can't Be Null Unless You Say So
- Functions Follow Flexible Rules
- Functions Actually Return Unit by Default
- Functions Can Be Single Expressions
- Single-Expression Functions Don't Have Curly Braces
- Single-Expression Functions Don't Use the return Keyword
- Single-Expression Functions Can Infer a Return Type
- Type Widening Results in the Widest Type Being Returned
- Functions Can Take Variable Numbers of Arguments
- A vararg Argument Can Be Treated Like an Array
- Functions in Kotlin Have Scope
- Local Functions Are Functions Inside Functions
- Member Functions Are Defined in a Class
- Extension Functions Extend Existing Behavior without Inheritance
- Extend an Existing Closed Class Using Dot Notation
- this Gives You Access to the Extension Class
- Function Literals: Lambdas and Anonymous Functions
- Anonymous Functions Don't Have Names
- You Can Assign a Function to a Variable
- Executable Code Makes for an "Executable" Variable
- Higher-Order Functions Accept Functions as Arguments
- The Result of a Function Is Not a Function
- Function Notation Focuses on Input and Output
- You Can Define a Function Inline
- Lambda Expressions Are Functions with Less Syntax
- You Can Omit Parameters Altogether
- Lambda Expressions Use it for Single Parameters
- it Makes Lambdas Work More Smoothly
- Lambda Expressions Return the Last Execution Result
- Trailing Functions as Arguments to Other Functions
- Lots of Functions, Lots of Room for Problems
- Chapter 11 Speaking Idiomatic Kotlin
- Scope Functions Provide Context to Code
- Use Let to Provide Immediate Access to an Instance
- let Gives You it to Access an Instance
- The Scoped Code Blocks Are Actually Lambdas
- let and Other Scope functions Are Largely about Convenience
- You Can Chain Scoped Function Calls
- An Outer it "Hides" an Inner it
- Chaining Scope Functions and Nesting Scope Functions Are Not the Same
- Nesting Scope Functions Requires Care in Naming
- Chaining Scope Functions Is Simpler and Cleaner
- Prefer Chaining over Nesting
- Many Chained Functions Start with a Nested Function
- You Can Scope Functions to Non-Null Results
- Accepting null Values Isn't a Great Idea
- Scope Functions Give You Null Options
- Scope Functions Work on Other Functions . . . in Very Particular Ways
- With Is a Scope Function for Processing an Instance
- with Uses this as Its Object Reference
- A this Reference Is Always Available
- with Returns the Result of the Lambda
- Run Is a Code Runner and Scope Function
- Choosing a Scope Function Is a Matter of Style and Preference
- run Doesn't Have to Operate on an Object Instance
- Apply Has a Context Object But No Return Value
- apply Operates upon an Instance
- apply Returns the Context Object, Not the Lambda Result
- ?: Is Kotlin's Elvis Operator
- Also Gives You an Instance . . . but Operates on the Instance First
- also Is Just Another Scope Function
- also Executes before Assignment
- Scope Functions Summary
- Chapter 12 Inheritance, One More Time, with Feeling
- Abstract Classes Require a Later Implementation
- Abstract Classes Cannot Be Instantiated
- Abstract Classes Define a Contract with Subclasses
- Abstract Classes Can Define Concrete Properties and Functions
- Subclasses Fulfill the Contract Written by an Abstract Class
- Subclasses Should Vary Behavior
- The Contract Allows for Uniform Treatment of Subclasses
- Interfaces Define Behavior but Have No Body
- Interfaces and Abstract Classes Are Similar
- Interfaces Cannot Maintain State
- A Class's State Is the Values of Its Properties
- An Interface Can Have Fixed Values
- Interfaces Can Define Function Bodies
- Interfaces Allow Multiple Forms of Implementation
- A Class Can Implement Multiple Interfaces
- Interface Property Names Can Get Confusing
- Interfaces Can Decorate a Class
- Delegation Offers Another Option for Extending Behavior
- Abstract Classes Move from Generic to Specific
- More Specificity Means More Inheritance
- Delegating to a Property
- Delegation Occurs at Instantiation
- Inheritance Requires Forethought and Afterthought
- Chapter 13 Kotlin: The Next Step
- Programming Kotlin for Android
- Kotlin for Android Is Still Just Kotlin
- Move from Concept to Example
- Kotlin and Java are Great Companions
- Your IDE Is a Key Component
- Kotlin Is Compiled to Bytecode for the Java Virtual Machine
- Gradle Gives You Project Build Capabilities
- When Kotlin Questions Still Exist
- Use the Internet to Supplement Your Own Needs and Learning Style
- Now What?
- Index
- EULA
System requirements
File format: PDF
Copy-Protection: Adobe-DRM (Digital Rights Management)
System requirements:
- Computer (Windows; MacOS X; Linux): Install the free reader Adobe Digital Editions prior to download (see eBook Help).
- Tablet/smartphone (Android; iOS): Install the free app Adobe Digital Editions or the app PocketBook before downloading (see eBook Help).
- E-reader: Bookeen, Kobo, Pocketbook, Sony, Tolino and many more (only limited: Kindle).
The file format PDF always displays a book page identically on any hardware. This makes PDF suitable for complex layouts such as those used in textbooks and reference books (images, tables, columns, footnotes). Unfortunately, on the small screens of e-readers or smartphones, PDFs are rather annoying, requiring too much scrolling.
This eBook uses Adobe-DRM, a „hard” copy protection. If the necessary requirements are not met, unfortunately you will not be able to open the eBook. You will therefore need to prepare your reading hardware before downloading.
Please note: We strongly recommend that you authorise using your personal Adobe ID after installation of any reading software.
For more information, see our eBook Help page.