(public).sospep.subjects ~ view article ~ dear-john-the-remaining-pain-points

<h1 style="text-align: center;">blackberry - pain points</h1>
<h2>[WHAT]</h2>
<ol>
<li>] In this post,&nbsp;after the release of bb os 10.2.1.1925 to gold status. Karl talks about some "remaining pain points" and some "new" bugs, as well as some features that still need work and some features that they "should be" working on. &nbsp;</li>
</ol>
<h2>[WHY]</h2>
<ol>
<li>] The newest Android runtime is very good -</li>
</ol>
<h2>[WHY NOT]</h2>
<div><ol>
<li>]&nbsp;</li>
</ol></div>
<h2>[WHERE]</h2>
<ol>
<li>] <a href="http://beforeitsnews.com/economy/2014/01/the-market-ticker-to-blackberrys-chen-the-remaining-pain-points-2585884.html" target="_blank">To BlackBerry's Chen: The Remaining Pain Points</a></li>
</ol>
<h2>[WHEN]</h2>
<ol>
<li>] 2014-01-dd</li>
</ol>
<h2>[EXAMPLE]</h2>
<ol>
<li><strong>Blacklists under user control.</strong>&nbsp; Users want this; the ability to blacklist numbers and/or PINs that are blocked from communicating with you. &nbsp;You should be able to set a phone number to either refuse to ring/supervise at all (e.g. the call gets shunted to voicemail) or to immediately pick up and disconnect without ringing, black-holing the call (at the possible cost of a minute of connection time to you.) &nbsp;For text messages being able to either black-hole it (dump it on the floor) or respond with a pre-set message is necessary. &nbsp;The same should be the case for PINs; I should be able to blacklist a PIN and either dump all incoming messages from it silently or reply with a message of my choosing automatically, again, without alerting the phone. &nbsp;Logging these would be nice too.<strong> </strong></li>
<li><strong>A reasonable number of user-defined profiles. &nbsp;</strong>Older BBOS devices had this; the present units have only normal, Vibrate-only and silent. &nbsp;In addition &ldquo;Bedside mode&rdquo; should be able to select any of the profiles. &nbsp;This would allow me to define a profile where only a handful of people can ring through and via the means I choose (e.g. calls AND texts from them are ok) while everything else is silenced. &nbsp;This is easy to implement and needs to be done.<strong> </strong></li>
<li><strong>Google Play.</strong>&nbsp; I know, I know, you can argue otherwise but BlackBerry is <strong><span style="text-decoration: underline;">intentionally</span></strong>&nbsp;blacklisting the Google Services Framework (GSF) with a <strong><span style="text-decoration: underline;">place-holder</span></strong>&nbsp;in their Android load that is not only non-functional <strong><em>it's a stub</em></strong>&nbsp;and contains no code at all. &nbsp;The apparent sole reason for this is to prevent anyone from handloading the <strong><span style="text-decoration: underline;">real</span></strong>&nbsp;GSF code. &nbsp;<strong><em>Either cut that crap out or support Google Play officially.</em></strong>&nbsp; The latter is better, incidentally, although I fully understand why BlackBerry doesn't want to do that &mdash; they are attempting to make money with their own app store (BlackBerry World.) &nbsp;<em><strong>The problem is that this strategy is not bearing fruit</strong></em>, so you either fix it or change it.</li>
<li><strong>The Android runtime is now <span style="text-decoration: underline;">very good</span>. &nbsp;It has one remaining bad place in it, I/O performance.</strong>&nbsp; In CPU and GPU (graphics) performance these devices now <strong><span style="text-decoration: underline;">outperform</span></strong>&nbsp;many contemporary middle-to-high-end devices, and are competitive with nearly all. &nbsp;Where it's not is on the I/O side. &nbsp;That's not an inherent limit in QNX, it's some sort of interaction between the virtual machine and the underlying OS. &nbsp;Find it and fix it, because it's the one thing that is limiting Android player performance right now and that &ldquo;snappy&rdquo; feel is important to people. &nbsp;Stick a couple of your rockstar programmers on this and figure out why you're getting 1/10th of the I/O performance you should be in the Android Player, release that as a patch and you're golden from an Android performance perspective.</li>
<li><strong>Allow changing <span style="text-decoration: underline;">Android</span>&nbsp;permissions.</strong>&nbsp; Google did, then took it back. &nbsp;Yes, I recognize that shutting off a permission for an Android app <strong><span style="text-decoration: underline;">may</span></strong>&nbsp;cause it to crash. So what? &nbsp;My device, my choice, period. &nbsp;Take <strong><span style="text-decoration: underline;">strong steps</span></strong>&nbsp;for user privacy. &nbsp;This is one of them. &nbsp;The phone allows this for native apps, allow it for Android apps. &nbsp;This is absolutely under BlackBerry's control.</li>
<li><strong>Get the freaking S/MIME email capability turned on.</strong>&nbsp; The phone knows how to do it. &nbsp;Quit screwing around &mdash; again, this is a <strong><span style="text-decoration: underline;">privacy</span></strong>&nbsp;issue. &nbsp;I know, I know, you want to see BES10 subs. &nbsp;I get it. &nbsp;BES10 does so much more than S/MIME that you're not cannibalizing anything here. &nbsp;Just do it, and do it now. &nbsp;While you're at it consider integrating PGP Email support into the native email client. &nbsp;Why? &nbsp;Because then I have both of the most-common means of sending and receiving encrypted emails <strong><em>native</em></strong>&nbsp;in the device. &nbsp;IOS offers only S/MIME, Android offers <strong><span style="text-decoration: underline;">none</span></strong>. &nbsp;Pain point <strong><span style="text-decoration: underline;">and</span></strong>&nbsp;differentiating feature, and it's cheap in cost (read: zero) to do S/MIME&nbsp;&nbsp;and minimal to do PGP.</li>
<li><strong>You <span style="text-decoration: underline;">added</span>&nbsp;a bug to the Android player in the last release. &nbsp;Fix it. </strong>&nbsp;Specifically, the file selector &ldquo;picker&rdquo; doesn't pick up files in the &ldquo;cloud&rdquo; (e.g. Dropbox, Box, your remote PC, etc) any more. &nbsp;If you hand-specify the pathname it works, so the player itself isn't broken, but the file picker is. &nbsp;This was working until 10.2.1.1925. &nbsp;<strong><em>Fix that crap</em></strong>&nbsp;as that violates the principle of least-astonishment, and anything in that category is an instant pain point.</li>
<li><strong>Full-Res HDMI Output</strong>. &nbsp;Decouple a plugged-in HDMI device from the screen resolution and take it from the native side. &nbsp;Yes, I know, developers were told you had a fixed screen resolution. &nbsp;So window the system for that so now I can have more than one &ldquo;full-screen&rdquo; window open at once. And this leads to&hellip;.</li>
<li><strong>Native apps, specifically OpenOffice or LibreOffice. &nbsp;</strong>Yes, off HDMI. &nbsp;I've brought this up before and it's <strong><span style="text-decoration: underline;">the</span></strong>&nbsp;piece that's missing in terms of making these devices viable replacements of other devices for a lot of business users.<strong><em>Unlike Apple and Samsung you have no tablet market to protect any more, so stop acting like you do.</em></strong></li>
</ol>
<h2>[HOW-TO]</h2>
<ol>
<li>]</li>
</ol>
<h2>[REFERENCE]</h2>
<ol>
<li>]</li>
</ol>
<h1 style="text-align: center;">&nbsp;</h1>

~ view article ~ Chapter] ch-002-blackberry FROM [ Book] companies IN [ libraries] business