Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 75, views: 23.190 •

De 'niet storen'-feature die in iOS 6 zit ingebakken zal na 7 januari weer als vanouds werken, zo heeft Apple beloofd. Na de jaarwisseling bleek dat de functionaliteit, die geluiden van binnenkomende notificaties uitzet, ook buiten de ingestelde tijd geluiden dempt.

Op de site van Apple is een verklaring gepubliceerd waarin het probleem met de 'niet storen'-feature wordt erkend. De fabrikant laat weten dat Do Not Disturb buiten de ingestelde tijd blijft werken, waardoor gebruikers geluiden voor binnenkomende notificaties van bijvoorbeeld telefoongesprekken of berichten missen. Volgens Apple zal de functie na 7 januari weer normaal werken. Tot die tijd wordt geadviseerd om handmatig 'niet storen' uit te zetten. Een verklaring voor de bug werd niet gegeven.

De problemen met 'niet storen' verschenen na de jaarwisseling, toen gebruikers op verscheidene fora en sociale media lieten weten dat de functionaliteit zichzelf niet automatisch uitschakelde. De functionaliteit werd door Apple geïntroduceerd in iOS 6 en kan er bijvoorbeeld voor zorgen dat gebruikers 's nachts niet gestoord worden door geluiden van binnenkomende notificaties.

Het is niet de eerste keer dat iOS-software met problemen kampt na een jaarwisseling. Twee jaar geleden gebeurde dat ook al, toen bleek dat ingestelde wekkers niet langer functioneerden. Ook toen liet Apple weten dat de functionaliteit zichzelf zou herstellen, maar toch bleef een aantal gebruikers nog last hebben van de bug.

Reacties (75)

Off topic: Leuk om de reacties hierover te lezen. Als persoon die niet professioneel in IT werkt heb ik weer wat bijgeleerd.

On topic:
Jammer wel dat Apple zo reageert. Ik begrijp (uit vorige posts) dat dit moeilijk en zinloos is om voor een zo korte tijd een bug fix te maken en dit uit te rollen. Maar dan zou ik PR gewijs dit niet melden. Door stomweg te zeggen 'wacht even, het lost zichzelf wel op'.
Dit is net hetgeen dat veel Apple gebruikers niet willen. Anders zouden ze niet voor het 'stabiele', altijd werkende Apple gaan (dit zijn de sterke punten die vaak aangehaald worden als ik me niet vergis).

Misschien beter zeggen dat je eraan werkt. . .
Als het zichzelf oplost weten de mensen toch niet of jij het nu was of niet.
(ITers natuurlijk wel omdat er geen patch was, maar de gemiddelde Apple gebruiker merkt niets)
Waarom is de oplossing; 'gewoon wachten', dan geen oplossing?
Dat is toch puur psychologisch dan?

Wat wil je dan? Een soort placebo patch op 6 januari waardoor men denkt dat er daadwerkelijk iets is gebeurd en het 7 januari opgelost is/lijkt?

Het s zinloos (door allerlei verschillende redenen) om een patch te maken op deze korte termijn. Dus waarom niet gewoon toegeven; er zit een fout in, maar het is dan over.

Waarschijnlijk in de volgende iOS release notes staat netjes een fix vermeld zodat het volgend jaar niet weer gebeurd.

Ik, maar dat is dan misschien persoonlijk, vind het een bedrijf meer sieren om hier gewoon open en eerlijk over uit te komen dan angstvallig zeggen dat je er 'druk mee bent' terwijl er niets gebeurd.

Apple is inderdaad stabiel en werkend, en misschien wel meer stabiel en werkend dan Windows, of niet. Dat is waarschijnlijk een kwestie van smaak/mening. Maar omdat er eens een bugje in zit (en zeker van deze orde van grootte) is het niet ineens geheel onstabiel en niet meer betrouwbaar.

Als deze post aanvallend overkomt; dat was zeker niet de bedoeling :) maar kon me toch niet helemaal vinden in jouw reactie.
Wat willen Apple gebruikers dan? ik denk er weinig hierom wakker liggen.
Als het vanzelf oplost ... mooi klaar, vind al verbazend men hierover 69 berichten weten te plaatsen.
Hoeveel tweakers heb je nodig om een dag en tijd uit te rekenen? ;)

Als ik er als ontwikkelaar naar kijk constateer ik het volgende: Uitvinden wanneer een wekker af moet gaan of een timer aan of uit, behoort niet tot de categorie rakettechnologie. Toch is dit iets waar Apple wel heel vaak mee worstelt. Het jaar 2013 is geen bijzonder jaar. Het is geen schrikkeljaar. Het is geen priemgetal. Mijn wekker heeft nog nooit een dag overgeslagen. Mijn alarmsysteem met timers heeft nog nooit een timer moment gemist.

Mogelijke oorzaak 1: te weinig Separation Of Concern in iOS. Waarom moet de wekker uitzoeken hoe laat het is? De tijd wordt bepaald door de tijd service in het OS. Een timer service kan op afgesproken momenten een event af te laten gaan. De wekker zoekt dus niet uit hoe laat ie af moet gaan. De Do not disturb hoeft op de zelfde manier niet te bepalen hoe laat het is.

Mogelijke oorzaak 2: het OS zodanig een zooitje is dat ontwikkelaars niet meer weten welke calls ze moeten doen om uit te vinden hoe laat het is.

Mogelijke oorzaak 3: ontwikkelaars zijn met van alles bezig, maar niet de goede dingen. Managers kijken alleen of het er goed uitziet.

Alle mogelijke oorzaken zijn wat mij betreft even zorgelijk,
Je hele reactie zit vol met conclusies die nergens op gebaseerd zijn. Je weet niet hoe de code er uit ziet, je weet niet hoe ze werken bij apple en je weet ook al helemaal niet hoe do not disturb werkt. Date & Time berekeningen zijn altijd lastig en fouten kunnen hier gewoon in kruipen, als jij hier nooit problemen mee hebt gehad is het heel erg goed mogelijk dat je code fout is en alleen werkt op bepaalde data ( wat vaak het geval is bij de meeste ontwikkelaars ), of de andere 'mogelijke oorzaak' dat je gewoon extreem onervaren bent. Als het nummer 86400 je bekent voor komt heb ik slecht nieuws voor je..

Er is een heel er goede reden waarom er zo verschrikkelijk veel API's beschikbaar zijn voor date & time, als het zo simpel was zou dat ook niet nodig zijn.

En natuurlijk neemt dit helemaal niet weg dat z'n fout niet echt moet gebeuren, maar bugs zijn er nou eenmaal en er staat zelfs een icoontje in je menubalk als do not disturb aan staat…

[Reactie gewijzigd door jabwd op 3 januari 2013 12:37]

Foutje moet kunnen, maar dat preserverende gedrag van Apple vind ik maar niets. Waarom kunnen ze de fout wel erkennen, maar niet uitleggen wat er mis gaat? Ze weten wat er is en dat het zichzelf oplost, maar kiezen ervoor geen uitleg te geven. Waarom moeten ze blijven doen alsof hun producten een soort magische wezentjes zijn? Ik heb nu bijvoorbeeld geen flauw idee of er een onzichtbare ongevraagde update gepusht wordt of dat het een probleem is dat zichzelf echt oplost.
@TheWim: Mijns inziens is jouw houding exact waarom het zo vaak mis gaat met datum en tijd berekeningen. Mensen (en dus developers) denken ten onrechte dat het heel makkelijk is en maken dus allemaal fouten.

Als je denkt dat het makkelijk is kun je er donder op zeggen dat je code buggy is.

Er zijn legio voorbeelden van fouten met data en tijd, juist omdat het vol zit met complexe patronen, vreemde uitzonderingen, verschuivende tijdzones, zomer- en wintertijd veranderingen (zoek voor de lol eens op in welke tijdzone Arizona ligt) en obscure regels. Van het Y2K probleem tot Android die pasgeleden de hele maand december miste tot dit probleem. Het komt erg vaak voor.

Ik denk dat als je developers zou vragen om een stukje code te schrijven dat bepaalt of iets een schrikkeljaar is zonder dat ze informatie er over mogen opzoeken, 90% het fout doet. De meeste mensen denken dat ieder jaar deelbaar door 4 maar niet door 100 een schrikkeljaar is en gaan daarmee meteen de mist in.

Net als bij iets complex als cryptografie wordt er bij datum en tijd berekening altijd aangeraden zoveel mogelijk bestaande en beproefde libraries te gebruiken om bugs te vermijden.

[Reactie gewijzigd door Maurits van Baerle op 3 januari 2013 12:38]

(en ook @jabwd) Zou kunnen, maar leg mij dan maar eens uit waarom de wekker geen last heeft van het probleem en de Do Not Disturb wel. Wat mij opviel is dat ze geen van beide last mogen hebben van de bug, of allebei wel. Blijkbaar is er een verschillende manier om tegen tijd/timers aan te kijken in beide applicaties. Hieruit trek ik mijn mogelijke conclusies.
Waarschijnlijk hebben ze te kampen met hetzelfde probleem als Microsoft in VisualBasic 6.0 / VBScript heeft zitten: http://support.microsoft.com/kb/200299

"When determining the week number of a date according to the ISO 8601 standard, the underlying function call to the Oleaut32.dll file mistakenly returns week 53 instead of week 1 for the last Monday in certain years."
Jammer, want ik wordt liever met rust gelaten - meer van dat soort graag! :+

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Assassin's Creed UnityFIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBDesktops

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013