This release is much larger than was the previous developer preview. It feels like Developer Preview 1 was âlow-hanging fruitâ, to give developers an additional month or so on the major changes for Android 15.
If your app is force-stopped, all pending intents are cancelled.
This change affects all apps, not just those targeting Android 15. I thought this
was already the behavior, but apparently it is not. For some devices that ship
with âtask managersâ that apply force-stop logic instead of only terminating app
processes, this change may really impact your users. Fortunately, at least,
you will now get ACTION_BOOT_COMPLETED
broadcast to your app so you can re-establish
anything that was canceled. However, there also is a new
ACTION_PACKAGE_UNSTOPPED
broadcast that you might consider. PackageManager
also now has an isPackageStopped()
function, so external parties can see if your app was force-stopped.
FINGERPRINT_SERVICE
was removed from Context
,
further impacting the already-deprecated FingerprintManager
.
Once you target Android 15, you will not be allowed to start some types of foreground services at boot time. I can see this causing problems for a fair number of apps.
Also, once you target Android 15, if your app supports Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai, then Android will use a taller font by default. This may cause UI glitches, such as text being cut off due to lack of sufficient vertical space.
Google taking PDF rendering seriously
is a nice improvement. PdfRenderer
was designed
for use in print previews, but developers have been trying to use it for arbitrary PDFs,
with varying results. And since many developers really do not want to use the userâs
preferred PDF reader, we were stuck with various workarounds.
The fact that the improved PdfRenderer
is being backported and apparently will be
wrapped in a Jetpack library also helps a great deal.
Support for deeplink filtering on query parameters and fragments is something that developers have been requesting for several years, so it is good that we are getting it, even if that is not something that can be backported.
Granular line-break controls, so we can keep titles contiguous, is a long-awaited text rendering improvement.
Similarly, developers have been asking for how to find out why the app was started for quite some time.
Screen recording detection
provides a nice middle ground between being oblivious to screen recording and using
FLAG_SECURE
to block it entirely. Note that you need
a new normal
permission
to enable this capability.
Resources
now has a registerResourcePaths()
method.
âThis will collect the package resourcesâ paths from its ApplicationInfo and add them to all existing and future contexts while the application is runningâ.
Getting and setting the system bar colors is now deprecated.
Your manifest components (activities, services, receivers, and providers) can be
protected with android:systemUserOnly="true"
.
This is supposed to limit that component to at most one instance, and that instance
can only be interacted with by the system user. My hope is that we can use this for
specific places where we want to plug into the framework but want to preclude arbitrary
other apps from trying to use the component.
Through DevicePolicyManager
, eligible apps can mandate âcontent protectionâ
or can allow user choice.
In this case, âcontent protectionâ means âscanning for deceptive appsâ. Similarly,
a device owner or policy owner can block NFC for certain users.
For app stores, ACTION_UNARCHIVE_PACKAGE
might prove interesting. Also, PackageInstaller
now has
a new set of APIs related to archiving apps.
There are new KeyEvent
key code values
for dedicated emoji picker and screenshot keys.
We can now limit drag-and-drop to be just within our app, even if we have multiple windows.
We can also specify an activity IntentSender
to use for unhandled drops.
When Google releases a new developer preview, I rummage through the API differences report, the high-level overviews, and even the release blog post, to see if there are things that warrant more attention from developers. I try to emphasize mainstream features that any developer might reasonably use, along with things that may not get quite as much attention, because they are buried in the JavaDocs.
Last year, a common complaint was how small Android 14 felt. This year, Android 14 seems huge by comparison. Android 15 DP1 is so small, Google did not bother writing a high-level overview of the changes, or at least it has not been published in an obvious location. Google usually does a bit of âsandbaggingâ in early developer previews, preferring to talk about changes one release later than when they are introduced. Still, this total lack of docs is rather stunning.
AccessibilityService
has long been used for things other than accessibility. Google
tried for a while to enforce this at the Play Store level, but if I recall correctly
they backed off.
AccessibilityService
now offers the ability to attach overlays to displays
(and to windows).
These are designed for UI that controls the accessibility itself, apparently.
I worry a bit that users will enable accessibility for an app for other reasons (e.g., help with playing some game), then get bitten by tapjacking attacks initiated by these overlays. Hopefully, these overlays have system-supplied âchromeâ that helps prevent this.
See also getOverlaySupport()
on Display
.
FileIntegrityManager
has been
around for a few years, but without a lot of functionality. Now we can call
setupFsVerity()
for a File
,
enabling some amount of tampering detection.
However, the documentation for applying it (in setupFsVerity()
) is seriously confusing.
Android 14âs QPR2 added support for partial screen sharing,
powered by MediaProjection
. This change is also folded into Android 15 DP1.
PackageManager
offers parseAndroidManifest()
.
This is designed for APKs that perhaps have not yet been installed. You get an XmlResourceParser
back, letting you traverse the manifest akin to using XmlPullParser
.
SystemClock
now offers uptimeNanos()
, the time since last boot, measured in nanoseconds.
JobManager
, via JobInfo
, now offers debug tags
and trace tags
for help with logging and traces.
MediaRoute2Info
now supports a bunch of additional remote media routes: to cars, computers,
game consoles, other phones, watches, tablets, or docked tablets.
We can now create notifications that have TV extensions, presumably for cases where a phone is tied to an Android TV device.
The parade of screen densities continues, as there is now support for a 390-dpi density.
]]>(hat tip to Prof. Matthew Green for raising awareness)
IMHO, governments are only part of the problem. Apple and Google can read your push messages. While both firms claim that messages are encrypted, that is only for âdata in motionâ, as they are sent over the Internet. Messages in their servers are unencrypted. Not only can they access the data, but they can hand it to whoever they want to, not just governments.
While the current focus is on âBig Techâ push message systems, the problem is more general than that. Any third-party data transport system has the same sort of problem. Services like PubNub, Amazon SNS, Stream, and others that offer âpublish/subscribeâ and similar sorts of message-based APIs are very useful, but generally their data is encrypted in motion and not at rest. Those firms can see your messages, as can anyone that those firms allow.
Roughly speaking, I see two main ways of addressing this.
The best is to not send anything of significance in the message itself. Use it as a trigger mechanism only. So, the message might contain some sort of verb identifying what it wants the app to do, but nothing else. The app would then use other communications options (e.g., Web service calls) to do whatever it is the trigger is requesting. This allows you to focus on securing those other communications options, and you care less about spying on your messages.
The other is to encrypt your message payloads so that only the recipient can read them. This can work, but key management is a pain as always. IMHO, use this approach only if the messages do not require any other communications to be useful â if you are going to have to make a Web service call anyway, there is little value in packing data into the message itself.
Neither of these approaches help much with metadata. The message system providers (e.g., Google) and their favored partners (e.g., governments) can still examine which apps are getting messages, at what times and for what accounts (e.g., Google accounts). The only way to avoid that is to avoid using a message system provider, such as hosting your own messaging server. That has its own problems (e.g., background process limits in Android).
Using a push message system provider often is unavoidable. Letting them have your data is avoidable, by encrypting that data or not having any meaningful data in the messages themselves.
]]>This really leaves TV Compose in the lurch. It will be used primarily for Android TV (a small fraction of the streaming device space) and for an ever-shrinking number of older Fire TV devices.
However, it further opens up an opportunity for some entrepreneur who wants to go after it.
App development for first-class TV devices will be highly fragmented now:
Here, âfirst-class TV devicesâ means devices where the app is installed on the device. Platforms like Chromecast, where the app is installed elsewhere, work substantially differently.
To me, this level of fragmentation, coupled with the nature of content-centric TV apps, suggests that a server-defined UI approach might work well. The TV apps would be largely white-labeled containers pointing to dedicated endpoints that serve the UI and the content viewed by that UI. Part of that server-defined UI would be a âstylesheetâ for branding elements (color scheme, logos, etc.). The browsing and playback UI would be driven by a mix of the available content and some general presentation patterns, with customization as desired by the customer.
I am uncertain if Rokuâs system will support this approach, as it is very proprietary and reminds me of 1990âs Visual Basic as much as anything.
It used to be that Roku plus Android would be 80+% of the North American TV streaming market. Eventually, that will become Roku plus React Native, as Amazon migrates to the new OS. Perhaps some enterprising developers will come up with something interesting to help bridge this gap and pick up the other smaller platforms as well.
]]>developers with newly created personal Play Console accounts will soon be required to test their apps with at least 20 people for a minimum of two weeks before applying for access to production
This seems trivial to bypass â 20 sockpuppet accounts and a test monkey might suffice. One imagines that somebody will create an underground service for this.
But Google can enact policies like this without much concern, as there is nowhere else for developers to go, by and large.
Thatâs why it will be interesting to see if Epic v. Google will touch upon a key anti-competitive tactic: banning app distributors from the Play Store. If your appâs principal job is to help people install apps, you are out of luck. Either you need to be a device manufacturer (e.g., Samsung) who can pre-install a store, or your potential users will need to sideload your store.
If this ban could be removed â by lawsuit or by legislation â there could be a more concerted effort to offer the Play Store meaningful competition. Even if Google were to continue with its policies, the competition would mean that there would be other useful avenues for affected developers to use.
]]>The series:
As noted in the previous post, I had a lot of success in the early years. Things might have peaked for me in 2014-15, when I had the opportunity to train hundreds of developers at a device manufacturer that was moving into Android⊠and then subsequently moved out of Android. đ€·
Perhaps that was foreshadowing, because by 2018, it was fairly obvious to me that CommonsWare was âcircling the drainâ, and there wasnât a thing I could do about it.
So, what happened?
As I noted earlier, I am not a marketer. CommonsWareâs marketing pretty much boiled down to: be useful to a large audience and hope that you get enough âtrue fansâ to keep the business afloat. This is not a bad approach when you can be âa big fish in a small pondâ. It does not work as well once the pond grows a lot, and in the case of Android, the pond grew to be the size of the Pacific Ocean. Either you:
Find some shallow eddy in which you can still be a âbig fishâ, by focusing on some niche while sticking with the same word-of-mouth marketing
Adopt other forms of marketing, or relationships with larger brands, that allow you to deal better with a larger set of competitors
Drown
I drowned. I did not plan ahead for finding some smaller niche, and I did not have any clue how to do anything else to keep CommonsWare at the forefront of developersâ minds.
By 2018, I started doing contract development work. I knew that the time I was working on contracts was time that I was not investing in CommonsWareâs future. I did, though, elect to declare âtech debtâ on The Busy Coderâs Guide to Android Development and started in on the second-generation books, such as Elements of Android Jetpack and Exploring Android. But I knew, even as I was writing those, that I didnât have much of a prayer with the Warescription model. I had too few subscribers and no clear plan for how to get more.
So, I did what a lot of people would do in that situation: I succumbed to depression. Or, in the words of Britainâs greatest secret agent: I lost my mojo.
In August 2019, through the efforts of Touchlab, I wound up doing contract work with a company called MIRROR. They made a fitness mirror, one where you can see the instructor and yourself while doing yoga, strength training, pilates, cardio work, stretching, etc. At the outset, that was just another contract.
In early 2020, I cut that contract to part-time status. I had one last shot at salvaging CommonsWare: dive into the niche of Jetpack Compose. I started a Jetpack Compose newsletter and had plans for books and a lot of the things you see others doing, such as an online catalog of composables and how to use them. My plan was to keep MIRROR going on a part-time basis as long as practical, while using the time to build up Compose expertise and content, in hopes of re-establishing myself.
But in June, MIRROR asked me to come back as a full-time contractor. I knew that if I did that, I had no shot at saving CommonsWare. But, I was tired and depressed, and I felt like CommonsWare had run its course. Plus, I really liked MIRROR, even after it was acquired by lululemon. So, I returned to full-time contractor status. And, in late 2021, I joined up as a regular employee, published the final edition of my books, and shut down CommonsWare.
2022 was a rough year for me emotionally. While I enjoyed the work with MIRROR, I was still depressed over my âfailureâ with CommonsWare⊠ignoring the fact that having the business survive that long and do as well as I did was a massive achievement. Few startups survive five years, and fewer still make it past their first decade. I beat both of those. Few developers will ever get the name recognition that I once had, and to a lesser extent perhaps still do. Yet, I could only focus on the fact that I couldnât sustain the business over the long haul. Plus, being in my early 50s, I felt like being an entrepreneur was something I might never do again.
Which brings us to 2023.
Early this year, I was inspired, not once, but twice, to turn my life around. I came to grips with my emotional state and got into therapy. I lost 25 pounds (hey, those MIRROR workouts really do work!). I saw what I was missing professionally due to my depression, and I finally got past the end of CommonsWare. I once again saw the joy in what I could do, and I started feeling like the Mark Murphy of old, for the first time in years. I started doing some âextracurricularâ things to try to help MIRROR (nĂ©e lululemon Studio), and while those may not ever have an impact, I felt good for trying to âmove the needleâ and make a substantial impact.
And now? I have plans for some more books. I am making no promises, but watch this space for further developments.
I learned a lot during the CommonsWare years, about myself perhaps more than about Android. For example, at times I was not very nice, and I will be forever chagrined at aspects of my behavior. While it is a clichĂ© to say that âI have become a better personâ, in my case I think it is true.
I am forever grateful to the Android developer community, from the experts to the newcomers,
for helping to grow Android to what it is today and to give me the opportunity to be useful.
I am thankful for my colleagues at MIRROR lululemon Studio
lululemon, for putting up with my foibles and letting me help along the way. And I will
be forever in debt to the person who inspired me twice this year to turn things around.
If I may be so bold to provide some advice, based on all of this:
Donât be afraid to chase your entrepreneurial dreams. The likelihood of cataclysmic failure is very low. The most likely form of âfailureâ is just to fizzle, and while it will seem painful in the moment, you will be fine. The possibilities of success, and the joy you will get from that success, are far more than worth the fizzle.
That said, if you start a business, do not only have a plan at the outset. Have a meta-plan for how you will adapt your plan to changes in the marketplace, in your situation, etc. Be in position to âtake a step backâ and look at your efforts with a clear and unbiased eye. And donât be afraid to change that plan⊠so long as you are not doing so on a whim and without clarity for how those changes will help.
Introverts can be entrepreneurs. Ask me how I know.
Be kind, and find ways to be kinder tomorrow than you are today.
The series:
In 2009, things started to pick up. As carriers started offering Android devices â and while Apple was only slowly reacting â interest in CommonsWare climbed:
I started delivering professional training on Android app development. Some of that was private for specific firms looking to jump on board Android. Some of that was public training, as I was the inaugural Android trainer for Big Nerd Ranch. The Big Nerd Ranch relationship only lasted a couple of years, as I was a contractor, and they eventually set up their own trainer talent. However, I struck deals to deliver training on behalf of other training firms in the US and Europe.
I entered an arrangement with Apress to re-publish The Busy Coderâs Guide to Android Development as Beginning Android. We did a few editions of that book together â I would distribute my copies, and they would distribute theirs. Eventually, I declined to continue with them, as sales of the Warescription (my subscription offering) outsold them by a lot, just on unit sales. Plus, direct sales of digital books had a lot higher profit margins than the royalty rate I got from Apress.
I started writing the occasional column for places like InfoWorld, before eventually setting up this blog and focusing on it.
All of that allowed me to quit my day job and work on CommonsWare full time.
I added âoffice hoursâ chats as a subscriber benefit, where I would hang out in a chat room for an hour and field whatever questions came up. That ran for a decade and probably contributed some to sales.
I also saw this little developer support site called Stack Overflow start to get some traction, and I decided that maybe I could help there. I answered my first question in May of 2009⊠and just kept going. Right now, it is up to 22,879 answers, though my contributions have definitely tailed off in the past several years.
Soon after, conferences started paying attention to Android. My first conference presentation was in 2010 at the Rich Web Experience, and the AnDevCon series began in 2011. All told, I presented at 38 conferences between 2010 and 2019. At several I delivered multiple presentations, so my total presentation count is probably around 50.
And the books flew off the (digital) shelves. I originally published both print editions (sold via Amazon) and the Warescription. In 2012 I discontinued the print editions because they did not sell very well and I was writing too much. Even at $40, then $45, per year, I had ~2,500 subscribers through 2015.
Not everything worked. I dabbled in developing libraries (the CommonsWare Android Components, or CWAC). For the early years, they were OK, but by modern standards they were awful. I tried various ways to extend the value of the Warescription, such as including training videos with the (self-distributed) book app. That didnât get a lot of attention, and I eventually stopped distributing the book as its own APK.
Still, though, I was doing quite well, professionally and financially, despite having limited marketing presence outside of âdoing good stuffâ. However, what goes up must come down, and I will explore that in my next and final post in this series.
]]>The series:
To recap: in early 2008, I realized that Android was the best option for me to dive deeply into smartphones, rather than iPhone. And I thought that a business model based around frequently-updated books on rapidly-moving technology might work.
So, I started writing. I spent evenings and weekends coming to grips with the nascent Android SDK, writing book chapters and sample apps along the way.
I also started contributing on the two Google Groups that Google had set up for
Android app development support. I knew that âword of mouthâ was going to be key for
my success, so I wanted to start early. However, in April and May of 2008,
I was definitely helping more on the
fringes â most of the attention in those groups were on the Google engineers
working on Android. Legends like Dianne Hackborn were active in the groups, guiding
us in understanding thorny questions like âWTF is a Context
?â and âwhy does my activity
get screwy after I rotate from portrait to landscape?â. There were perhaps a dozen
key Google contributors on those groups, and we relied on them fairly heavily.
And then in late May, the Google contingent stopped posting on those groups.
There was no âgoodbyeâ, or âhey, we need to focus on other things for a whileâ, or any other sort of announcement. One day, they were just gone. Eventually, we heard via âthe grapevineâ that top management (presumably Andy Rubin) had screamed fairly loudly about Googlers being involved with the community, particularly with deadlines looming. That seems plausible (both the justification and the screaming), though I never attempted to get corroboration for that story.
The reverberations from that lingered for years, as it seemed as though Google engineers were prevented from even acknowledging that the community existed. I distinctly remember an early Google I|O conference session, where Romain Guy was struggling not to say âActionBarSherlockâ when trying to answer a question about ActionBarSherlock, Jake Whartonâs legendary early UI framework. It was quite some time before whatever sort of âgag orderâ they were under seemed to lapse, and longer still before Android got a solid developer relations team.
But, in May 2008, the net was that the vast majority of our Android developer support system vanished without a trace. It was just a few of us independents left to help others, especially those like myself and Reto Meier, who were working on Android app development books. I re-doubled my support efforts, to try to fill the gap. And, weeks after the summer of silence began, I released the initial edition of The Busy Coderâs Guide to Android Development.
The combination of the book and the support posts on the Google Groups started to establish my reputation as being a leading expert on Android app development.
This is where âyou make your own luckâ starts to come in. I did the work to identify a business model. I did the work to identify an area to apply the business model towards. I did all kinds of work to execute on that business model, starting with writing a book very quickly and supporting the pre-hardware Android developer crowd. That set me up to capitalize on the âknowledge gapâ that arose when the Google engineers left the Google Groups. I did not create that gap â some Google executive did â but I was in position to fill it. The phrase really should be âyou work to put yourself in a place to leverage luck when it arisesâ, but thatâs a bit wordy.
Those Google Groups have long been âresigned to the dustbin of historyâ, and even old-timers like myself rarely think about them. I wound up being better known for answering support questions somewhere else⊠and I will talk more about that âsomewhere elseâ in the next post in this series.
]]>The series:
Rolling back to where the first post ended, in late 2007:
Apple announced that they would have a real SDK for developing iPhone apps in early 2008
Google released the first developer preview of Android
I started experimenting with Android. The SDK was a bit odd, and the docs were a bit modest, but for a developer preview, it was reasonable. Moreover:
It was based on Java, and I had a reasonable amount of experience with it
It was open source, and I was a definite fan of that, to the point where my âdaily driverâ machine was powered by Linux
At the time, I trusted Google far more than I trusted Apple
However, Android was still just a preview. As it turned out, it was nearly a year until hardware became available to the public. Apple was already shipping iPhones. If you compare sales back then to today, Apple was not selling very many iPhones. It was quite some time before Android devices surpassed iPhones in sales. And, as 2007 came to a close, it was fairly clear that the iPhone SDK would do better âout of the gateâ, just because they had an active user base.
So, I waited.
On March 6, 2008, Apple released their SDK. From my vantage point, it was an unmitigated disaster:
It was based on Objective-C. I remember when Objective-C came out â I looked at the syntax and wondered why anyone would use it.
It was based on Cocoa, the macOS/OS X UI framework. I had no experience with that. Of course, I had no experience with Androidâs widget set either, but at least there, I was on a level playing field with just about everyone else. I expected that macOS developers would be in better shape to develop iPhone apps than I would be.
It required a Mac for development. This wasnât the end of the world, as I used to use a 15â iMac as my main desktop and so had OS X experience. Still, it wasnât what I wanted.
Most importantly, you had to sign an NDA. It is very difficult to write books when you are not allowed to write books. It is very difficult to answer developer questions when you are not allowed to answer developer questions. And so on.
Shortly thereafter, I turned my attention to Android, and a few months later, I had an early edition of The Busy Coderâs Guide to Android Development available. And, in October 2008, I waited in the early hours of the morning outside a T-Mobile store in the greater Philadelphia area, to beat the rush of people who I was sure were going to line up to purchase the T-Mobile G1 (a.k.a., the HTC Dream), the first widely-available Android phone in the US.
As it turned out⊠I was the only one waiting. And the guy at the store thought I was nuts.
In a parallel universe, Android âdied on the vineâ. In this universe, Appleâs hubris bit them in the posterior once again. In the US, they established AT&T as the exclusive carrier for iPhones. The other US carriers struck deals with HTC, Motorola, and others for Android phones, giving Android an opening. By the time Apple relented and got iPhone models available for all the major US carriers, Android was established and would go on to global dominance.
Androidâs success meant that I had the potential for success, âriding the coattailsâ as it were. It still was far from guaranteed that I would do well. Fortunately, 2008 gave me an opportunity to establish some credentials, a topic that I will cover in the next post.
]]>The series:
Part of the challenge in explaining where CommonsWare came from is that so much has changed since the mid-2000âs. What was innovative at the time is fairly ordinary today.
Nowadays, online documentation for operating systems, programming languages, libraries, and tools is not merely expected to exist, but to be good. 15 years ago, that would have been unrealistic. We were lucky to have any of that. Instead, most âbulk formâ knowledge transfer came in the form of books from traditional publishers: OâReilly, Apress, Prentice-Hall PTR, and various others.
Traditional publishers, particularly at that time, were far from nimble. It might take 6-18 months for a book to get published. That was a big problem for fast-moving technologies â by the time the book âhit the shelvesâ, it was already at risk of being out of date. And while e-books existed, if they were published by traditional publishers, they had the same publishing workflow and the same publishing delays. Besides, e-books were fairly new â the Amazon Kindle did not debut until November 2007, around the time that Android was announced.
At that time, I was fairly certain that e-books would do well for programming guides and similar sorts of book subjects. However, since e-books were still nascent, banking a business on them seemed risky. At the same time, my vision for CommonsWare was to provide up-to-date help for programmers, and traditional publishers were far too slow.
Fortunately, I stumbled upon Lightning Source.
Lightning Source offered print-on-demand services, and through Ingram were tied into Amazon. You could self-publish a print book on Amazon without having to have pre-ordered hundreds of copies of the book. Instead, Lightning Source would respond to an Amazon order by printing a single copy of the book (or however many were ordered) and shipping it to the customer directly. This meant I could control my own publishing timelines, simply by listing an updated title on Amazon with fulfillment handled by Lightning Source. Much to my amazement, the quality of the book was very good, more than sufficient for my needs.
Lightning Source for printed books, coupled with e-books, meant that I could offer continuously-updated content:
I could sell e-books on a subscription basis, publishing updates as frequently as I wanted, to track changes in a subject or to expand coverage
I could sell print editions of that same content via Amazon, updated less frequently than the e-books (say, once per year), but still much more frequently and quickly than any traditional publisher could match
Nowadays, this is all taken somewhat for granted. Selling subscriptions to continuously-updated digital content, even by solo entrepreneurs or on a hobby basis, is commonplace. At the time, very few people were doing this, and I was breaking new ground to an extent.
In terms of the business model, I did not want to charge a lot for the e-book subscriptions â I wanted it to be in line with books, though perhaps on the more expensive end. I settled on $45 per year. Profit margins on self-published and self-sold e-books were tremendous, as I only had to pay credit card processing fees (or the equivalent for services like PayPal). ~95% profit margin is quite a contrast from self-published print books sold through Amazon (~55% profit margin), let alone royalties from traditional print publishers (equivalent of ~10% profit margin). Still, I would need more than â1000 true fansâ, but I hoped that I would âmake it up in volumeâ. Plus, I thought that maybe I could offer some professional services to supplement the book publishing, such as consulting or training.
So, I had the the âreason to buyâ: get up-to-date programming guides in what was for the time a fairly convenient format (e-books). I still needed to settle on the specific subject matter: Android or iPhone. That not only meant what area I would need to focus in, but also what avenues I would use to âconnect with fansâ. I will explore that decision in the next post.
]]>